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ABSTRACT 


In  order  for  an  agent  to  be  credible  in  simulating  a  human  opponent  in  a 
first-person  combat  simulation,  it  must  be  able  to  find  and  use  cover  from  direct 
fire  weapons.  The  ability  to  find  cover  is  fairly  intuitive  for  humans,  but  current 
attempts  at  replicating  this  ability  in  computer  simulations  and  video  games  have 
been  either  simplistic  or  totally  missing.  This  thesis  explores  a  range  of 
algorithms  which  computer  agents  can  use  for  finding  cover  from  direct-fire 
weapons  in  high-detail,  dynamic,  three-dimensional  environments.  The  first 
method  treats  the  enemy  as  a  point  light  source  and  uses  binary  space  partition 
trees  to  create  shadow  volumes  to  find  areas  of  cover.  The  second  method  uses 
a  depth-mapping  technique  to  find  potential  areas  where  the  agent  could  get 
behind  cover.  The  third  method  uses  a  sensor  grid  centered  on  the  agent  that 
allows  it  to  check  the  area  around  it  for  cover  locations.  We  implemented  the 
sensor  grid  technique  inside  of  the  first-person  shooter  computer  game 
America’s  Army:  Operations  as  a  proof  of  concept. 
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I.  INTRODUCTION 


A.  THESIS  STATEMENT 

A  range  of  algorithms  exists  that  can  be  used  to  improve  the  current  ability 
of  agents  to  find  cover  from  direct  fire  in  dynamic,  three-dimensional,  dynamic, 
simulated  environments. 

Agents  in  current  three-dimensional,  dynamic,  simulated  environments 
lack  the  ability  to  take  cover  from  direct  fire  due  to  a  lack  of  information  about 
their  immediate  surroundings.  A  range  of  algorithms  exists  that  can  provide  an 
agent  with  additional  information  about  its  surroundings,  making  it  possible  to 
produce  more  realistic  behavior. 

B.  MOTIVATION 

The  United  States  Military  has  and  will  continue  to  increase  its  use  of 
simulations  to  train  its  soldiers  and  to  perform  operations  analysis.  While 
simulations  cannot  completely  replace  live  training  currently,  they  do  offer  some 
significant  benefits.  Simulations  are  less  expensive  than  live  training  overall 
when  all  associated  costs  are  included.  Simulations  are  safer  than  live  training, 
especially  in  force-on-force  situations  where  two  live  units  actively  fight  each 
other.  Simulations  do  not  have  the  environmental  impact  of  live  training. 
Simulations  also  allow  for  training  in  a  controlled  environment  where  the 
conditions  of  the  exercise  can  be  exactly  controlled  and  repeated  as  many  times 
as  it  is  necessary  to  reach  the  trainer’s  goals.  For  these  reasons  and  more,  the 
United  States  Military  has  turned  to  simulations  in  order  to  maintain  the  training 
level  of  its  units  and  soldiers. 

In  many  cases,  it  is  preferable  to  use  computer-controlled  agents  to  act  as 
the  enemy  forces  in  simulations  rather  than  place  them  under  the  control  of 
another  person.  Many  times  the  hardest  part  of  a  military  task  is  coordinating 
actions  between  units  to  get  combined  effects  on  the  target.  If  you  have  two 
units  to  train,  computer-controlled  agents  can  allow  you  to  train  them  together 
rather  than  opposing  each  other.  This  also  allows  you  to  run  higher-level 
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scenarios.  Instead  of  eight  live  simulators  opposing  eight  live  simulators,  you 
can  have  sixteen  live  simulators  opposing  sixteen  computer-controlled  agents. 
This  is  a  more  effective  use  of  simulation  assets,  which  may  be  in  high  demand. 

In  order  for  computer-controlled  agents  to  provide  a  positive  training 
effect,  they  must  look  and  behave  as  closely  as  possible  to  their  real-life 
counterparts.  If  the  behavior  of  the  agent  is  significantly  different  from  real-life, 
the  trainee,  in  essence,  is  training  on  a  different  task  from  the  one  that  they  are 
supposed  to  learn.  While  there  may  be  some  cross-over  in  related  skills,  it  is 
unlikely  that  they  will  be  able  to  reach  full  proficiency  in  the  target  task. 

One  of  the  areas  where  current  computer-controlled  agent  behavior  is 
unrealistic  is  in  the  ability  for  them  to  take  cover  when  fired  upon  by  direct  fire 
weapons.  The  basic  ability  to  hide  and  take  cover  is  something  that  everyone 
learns  as  they  grow  up.  The  military  builds  on  this  knowledge  and  trains  its 
soldiers  even  further  how  to  find  and  use  cover.  It  is  an  essential  survival  skill  on 
modern  battlefields  dominated  by  projectile  weapons.  However,  in  most  current 
simulations  and  games,  the  computer-controlled  forces  have  only  a  simplified 
understanding  of  cover  or  none  at  all.  This  leads  to  computer-controlled 
opponents  that  stray  out  into  the  open  making  themselves  easy  targets.  This 
does  not  provide  the  trainee  with  the  necessary  tough,  realistic  training. 

In  order  to  provide  effective  training  in  computer  simulations,  the 
computer-controlled  agents  should  be  able  to  find  and  take  cover  like  a  human 
would  in  the  same  situation.  We  can  do  this  through  a  variety  of  methods  that 
increase  the  agent’s  knowledge  of  the  world  around  him.  That  knowledge  can 
then  be  used  to  produce  believable  behaviors. 

C.  THESIS  ORGANIZATION 

The  remainder  of  this  thesis  is  organized  as  follows: 

•  Chapter  II:  Description  of  the  Application  Area.  Detailed 
description  of  cover  and  concealment,  an  overview  of  some  of  the 
processes  involved  in  how  we  find  cover,  and  information  on 
computer  processes  useful  in  finding  cover. 
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•  Chapter  III:  Related  Work.  Some  of  the  techniques  currently 
used  in  military  simulations  and  computer  games  for  finding  cover. 

•  Chapter  IV:  Conceptual  Models.  Descriptions  of  the  three 
algorithms  that  we  developed  in  order  to  provide  an  agent  with 
knowledge  of  cover  around  it.  These  are  the  Binary  Space  Partition 
Shadow  Volume  Method,  the  Depth  Mapping  Method,  and  the 
Sensor  Grid  Method. 

•  Chapter  V:  Implementation  of  the  Sensor  Grid  Model.  A 

detailed  description  of  how  we  implemented  the  Sensor  Grid 
Method  in  the  computer  game  America’s  Army:  Operations. 

•  Chapter  VI:  Conclusions  and  Future  Work.  A  discussion  of 
general  conclusions  of  all  the  methods  we  researched  and 
suggestions  for  future  research  to  improve  them. 
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II.  DESCRIPTION  OF  THE  APPLICATION  AREA 


A.  INTRODUCTION 

This  chapter  provides  a  description  of  some  of  the  issues  that  are 
important  when  developing  cover  algorithms  for  use  in  computer  simulations. 
First  we  must  understand  what  cover  is  and  how  it  is  different  from  concealment. 
Second,  we  look  at  human  performance  issues  related  to  the  issue  of  how  we 
are  able  to  find  cover  in  real  life.  Finally,  we  must  consider  the  tools  available  in 
computer  simulations  to  help  our  agents  find  cover  and  the  limitations  of  these 
tools. 

B.  COVER  AND  CONCEALMENT 

1.  Cover 

Cover  is  a  physical  object  that  can  prevent  a  weapon  system  from  causing 
damage  to  you  by  deflecting  or  absorbing  its  energy  [8],  Common  examples  of 
real-life  cover  from  direct-fire  weapons  include  rocks,  trees,  earthen  berms,  and 
solid  walls.  A  good  piece  of  cover  should  be  large  enough  for  you  to  get  your 
entire  body  behind  and  should  be  able  to  protect  you  from  the  weapon  being  fired 
at  you. 

An  object  that  provides  cover  for  one  weapon  system  may  not  provide 
cover  against  another  one.  For  example,  a  cinderblock  wall  provides  good  cover 
from  most  small  arms  fire  from  rifles.  However,  it  will  provide  no  cover  against 
heavy  machine  guns  that  are  able  to  fire  right  through  it.  In  this  case,  the 
cinderblock  wall  would  only  provide  concealment.  In  order  for  cover  to  be 
effective,  it  must  be  able  to  stand  up  to  the  force  exerted  on  it  by  the  weapon. 

Interestingly  enough,  several  feet  of  packed  earth  provides  better 
protection  against  bullets  than  rock  does.  When  bullets  strike  a  sufficiently  large 
amount  of  earth,  their  impact  is  absorbed  and  they  stop.  When  bullets  strike  rock 
they  tend  to  ricochet  and  also  fracture  the  rock  sending  small  pieces  of 
secondary  shrapnel  flying  all  over  the  place.  The  ricochets  and  the  flying  pieces 
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of  rock  can  wound  you  or  other  people  near  you.  If  hit  with  sufficient  force,  rock 
can  also  crumble  to  the  point  where  it  provides  no  cover  at  all. 

Cover  is  also  direction  dependant.  As  the  position  of  the  weapon  system 
changes  the  area  of  cover  provided  by  an  object  also  changes.  Depending  on 
the  shape  of  the  object  and  the  position  of  the  weapon,  the  object  may  provide 
no  cover  at  all.  If  you  take  cover  behind  a  log  from  someone  firing  at  you  from 
the  ground  floor  of  a  building,  you  may  not  have  any  cover  if  that  person  moves 
up  to  the  second  or  third  floor  where  they  can  see  over  the  log. 

2.  Concealment 

Concealment  is  anything  that  has  a  negative  impact  on  the  ability  of 
someone  to  accurately  target  you  with  a  weapon  system  by  affecting  their  ability 
to  see  you.  Common  examples  of  concealment  are  brush,  tall  grass,  smoke,  and 
fog.  These  are  all  objects  that  you  can  place  between  you  and  a  person  firing  at 
you  to  keep  them  from  accurately  targeting  you.  Less  common  examples  of 
concealment  are  shadows  and  personal  camouflage.  In  these  cases,  there  is  no 
physical  object  between  you  and  the  person  firing  at  you,  but  they  can  still 
prevent  the  enemy  from  accurately  targeting  you. 

3.  Cover  Versus  Concealment 

Cover  and  concealment  are  closely  related  to  each  other.  The  vast 
majority  of  objects  that  provide  cover  will  also  provide  concealment.  Generally, 
objects  that  are  large  enough  and  strong  enough  to  stop  a  bullet  will  also  prevent 
the  enemy  from  seeing  you.  However,  the  opposite  is  not  generally  true. 
Objects  that  provide  concealment  do  not  always  provide  cover.  It  is  a  common 
saying  in  the  U.S.  Army  that  “cover  provides  concealment,  but  concealment  does 
not  provide  cover”.  This  makes  it  very  easy  for  most  people  to  keep  them 
straight. 

The  only  notable  example  that  we  were  able  to  find  of  an  object  that 
provides  cover,  but  not  concealment,  is  bulletproof  glass.  Bulletproof  glass  is 
specifically  designed  to  stop  bullets  and  allow  you  to  see  through  it.  Even  so,  it 
can  only  stop  bullets  up  to  a  certain  size  and  for  only  a  certain  number  of  shots 
before  it  ceases  to  provide  protection. 
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4.  Cover  from  Other  Types  of  Weapons 

One  important  distinction  in  types  of  cover  is  the  difference  in  cover  from 
direct-fire  weapons  and  indirect-fire  weapons.  Direct-fire  weapons  are  generally 
designed  to  cause  damage  by  directly  striking  the  target.  Their  energy  travels 
over  a  relatively  flat  and  narrow  trajectory.  Examples  of  direct-fire  weapons  are 
rifles  and  lasers.  In  order  to  take  cover  from  this  type  of  weapon,  you  want  to 
place  the  object  providing  you  cover  between  you  and  the  person  firing  at  you. 
This  is  different  for  indirect-fire  weapons  and  area-effect  weapons. 

Indirect-fire  weapons  are  those  that  do  not  follow  a  direct  path  to  the 
target.  They  generally  travel  in  a  high,  arching  trajectory  that  takes  them  over 
intervening  objects  to  attack  the  target  from  above.  Examples  of  common 
indirect-fire  weapons  are  artillery  shells,  mortars,  and  bombs.  In  order  to  take 
cover  from  indirect-fire  you  need  to  put  the  cover-producing  object  between  you 
and  the  flight  path  of  the  indirect-fire  weapon.  This  is  what  the  military  calls 
“overhead  cover”. 

Since  indirect-fire  weapons  usually  have  a  very  low  chance  of  directly 
hitting  their  targets,  they  generally  have  explosives  in  them  that  let  them  cause 
damage  over  an  area.  In  order  to  take  cover  against  area-effect  weapons,  the 
position  of  the  enemy  is  not  as  important  as  where  round  lands.  This  is  where 
the  damage  will  be  coming  from.  If  a  hand  grenade  lands  behind  you,  you  need 
to  have  cover  between  you  and  the  hand  grenade,  not  between  you  and  the 
enemy  that  threw  it.  In  many  cases  with  indirect-fire  weapons,  you  will  know  that 
you  are  under  attack,  but  not  know  where  the  round  will  land.  In  this  case,  your 
best  bet  is  to  find  a  location  that  provides  cover  from  the  largest  number  of 
probable  landing  spots. 

C.  HUMAN  PERFORMANCE 

1.  How  Humans  Find  Cover 

In  order  to  program  an  agent  to  find  cover,  we  first  had  to  look  at  how 
humans  find  cover.  Unfortunately,  there  is  not  a  lot  of  existing  research  in  this 
area.  Even  basic  military  training  manuals  assume  that  a  person  already  has  an 

understanding  of  how  to  take  cover.  They  only  list  several  things  that  can 
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provide  cover  and  tell  you  to  protect  yourself  from  enemy  fire  by  using  cover.  In 
order  to  determine  how  humans  actually  find  cover,  we  relied  on  our  experience 
in  the  military  and  common  sense. 

A  person  wishing  to  take  cover  generally  follows  these  steps: 

•  Determine  where  the  threat  is  coming  from. 

•  Look  for  objects  or  features  that  may  provide  cover  from  the  threat. 

•  Determine  if  these  locations  can  be  reached. 

•  Choose  a  place  to  take  cover. 

•  Move  to  that  location. 

Due  to  the  parallel  nature  of  brain  processes,  these  steps  do  not  have  to 
execute  sequentially.  In  fact,  they  may  not  always  occur  in  this  order  and  at 
times,  some  of  the  steps  may  be  left  out.  What  we  are  attempting  to  list  here  are 
the  minimum,  necessary,  logical  steps  to  find  a  complete  solution  to  the  cover 
problem.  There  may  be  shorter  and  quicker  solutions,  such  as  simply  dropping 
to  the  ground,  but  they  will  not  guarantee  that  you  are  in  cover,  if  cover  is 
available. 

The  steps  listed  above  may  seem  like  a  lot  to  think  about  when  your  life 
may  be  in  danger,  but  humans  seem  to  be  able  to  do  it  all  in  a  fraction  of  a 
second.  In  addition,  there  may  be  a  significant  amount  of  preprocessing  going 
on  when  a  person  knows  that  they  are  in  a  dangerous  situation  where  they  may 
need  to  take  cover. 

As  we  move  around,  we  continuously  create  a  mental  model  of  the  area 
around  us.  This  is  why  we  can  do  things  like  back  up  without  looking  behind  us 
or  walk  up  stairs  without  looking  at  our  feet  for  every  step.  We  use  our  mental 
model  of  the  surroundings  to  plan  our  interaction  with  the  environment.  This 
mental  model  is  not  as  high  resolution  as  a  deliberate  scan  and  interpretation  of 
the  area,  but  it  allows  us  to  take  quick  action  when  necessary. 

Experienced  infantrymen  also  tend  to  plan  their  use  of  cover  ahead  of 
time.  While  out  of  direct  combat  with  the  enemy,  they  will  note  good  locations  to 
take  cover  as  they  move  along.  When  moving  while  in  direct  combat  with  the 
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enemy,  they  will  plan  short  moves  where  they  limit  their  exposure  before  taking 
cover  at  a  new  location. 

a.  Determine  the  Direction  of  the  Threat 

In  order  to  make  the  most  effective  use  of  cover  you  must  know  the 
direction  that  the  threat  is  coming  from.  If  you  directly  observe  the  threat,  then 
this  is  very  easy.  If  you  do  not  directly  observe  the  threat,  then  you  must  analyze 
secondary  factors  to  determine  the  most  likely  position  of  the  enemy.  Some  of 
these  factors  include:  sound,  impact  of  rounds,  and  previous  intelligence  on 
possible  enemy  locations.  In  the  absence  of  any  information  at  all  on  the 
direction  of  the  threat,  we  tend  to  pick  the  piece  of  cover  that  offers  the  best 
protection  from  the  widest  area.  Another  option  in  this  situation  is  to  move  back 
to  the  area  where  we  came  from  under  the  assumption  that  we  must  have  just 
come  into  view  prompting  the  enemy  to  fire. 

b.  Determine  Which  Positions  Provide  Cover 

Once  the  position  of  the  threat  has  been  determined,  you  must 
determine  which  objects  provide  cover  from  that  threat.  There  are  actually  two 
steps  in  this  process,  determining  the  area  of  cover  offered  by  the  object  and 
determining  if  the  object  provides  cover  or  concealment.  There  is  no  clear 
evidence  of  the  any  order  for  these  two  steps. 

Determining  the  area  of  cover  offered  by  the  object  involves  mental 
simulation.  Through  mental  simulation,  you  project  lines  from  the  threat  location 
to  the  object.  These  lines  allow  you  to  determine  the  area  on  the  far  side  of  the 
object  from  the  threat  where  there  will  be  cover.  Fortunately,  humans  are  fairly 
adept  at  doing  this  type  of  mental  simulation  [14].  It  has  been  an  important 
survival  mechanism  for  us  to  be  able  to  keep  a  three-dimensional  map  of  our 
surroundings  in  our  heads.  In  military  terms,  this  is  sometimes  referred  to  as 
“situational  awareness”.  It  is  an  understanding  of  the  area  around  you,  your 
position  in  that  area,  and  the  potential  things  that  can  affect  you  in  that  area. 

Determining  whether  an  object  offers  cover  or  concealment  against 
a  threat  is  a  matter  of  learning  and  experience.  You  must  make  a  quick 

judgment  about  the  composition  of  the  object  to  determine  if  it  is  sufficient  to  stop 
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the  threat.  During  military  basic  training  when  recruits  first  learn  to  take  cover, 
they  often  make  poor  choices.  They  correctly  move  themselves  out  of  line  of 
sight  from  the  threat,  but  they  try  to  take  cover  behind  objects  that  provide  little  or 
no  real  protection.  After  becoming  more  familiar  with  the  capabilities  of  different 
weapon  systems,  they  are  much  more  adept  at  quickly  determining  good  cover 
locations. 

c.  Determine  Which  Positions  Can  Be  Reached 

Once  you  have  determined  which  positions  provide  cover,  you  must 
determine  which  ones  are  reachable  and  how  long  it  will  take  to  reach  them.  A 
cover  position  that  you  cannot  reach  or  takes  too  long  to  reach  will  not  be  useful. 

d.  Chose  a  Cover  Position  to  Take 

In  order  to  choose  the  best  cover  position,  you  must  consider  many 
factors.  You  will  have  to  make  this  decision  very  quickly  and  under  extreme 
duress.  Your  life  may  well  depend  on  it. 

You  must  consider  the  quality  of  cover  provided  by  the  object  or 
feature  providing  cover.  You  must  determine  if  the  object  is  sufficient  to  stop  the 
threat  from  which  you  are  taking  cover. 

You  must  consider  the  size  of  the  area  of  cover  provided  by  the 
object.  A  larger  area  provides  you  more  maneuverability  and  is  easier  to  get 
behind.  A  larger  area  decreases  the  chance  that  you  try  to  take  cover  and  find 
that  you  cannot  fit  yourself  completely  inside  the  area.  The  ability  to  move  within 
the  currently  covered  area  also  means  that  you  have  more  room  to  adjust  if  the 
threat  changes  position. 

A  good  cover  location  will  also  have  a  good  egress  route.  A  good 
egress  route  provides  you  with  a  way  to  move  out  of  the  immediate  area  with 
continuous  cover  from  the  threat.  Taking  cover  behind  an  object  without  a  good 
egress  route  will  can  leave  you  pinned  down  in  that  position  and  unable  to  move 
without  taking  serious  damage.  When  this  happens,  the  enemy  is  often  able  to 
move  to  another  position  where  the  object  provides  you  no  cover  at  all. 
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You  must  consider  how  long  it  will  take  you  to  reach  the  cover 
location.  You  want  to  minimize  the  amount  of  time  that  you  expose  yourself  to 
the  threat.  Often  this  is  a  simple  matter  of  distance  to  the  location.  However, 
difficult  terrain  can  slow  your  movement  and  have  a  huge  impact  on  the  time  it 
takes  to  reach  the  position.  A  good  cover  location  must  be  quickly  reachable, 
e.  Move  to  the  Cover  Position 

The  last  step  in  taking  cover  is  to  move  to  the  cover  location  you 
chose.  The  key  here  is  to  minimize  your  exposure  to  enemy  fire.  Sometimes 
this  means  you  should  move  as  quickly  as  possible.  Sometimes  this  means  you 
need  to  drop  to  the  ground  and  crawl  into  the  cover.  The  situation  will  dictate 
which  method  you  should  use. 

2.  Taking  Cover  from  Multiple  Attackers 

In  most  of  the  situations  we  have  described  above,  we  have  talked  about 
taking  cover  from  one  threat.  However,  it  is  a  more  common  situation  in  combat 
that  you  will  be  facing  multiple  threats  at  the  same  time.  These  threats  may  be 
all  in  the  same  direction  or  in  several  directions.  One  solution  is  to  analyze  the 
cover  from  each  threat  and  find  the  intersection  of  these  locations.  While  this  will 
provide  you  with  the  best  answer,  the  computational  expense  could  be 
enormous.  A  better  solution  may  be  to  analyze  the  cover  from  the  threats  that 
are  on  the  far  ends  of  the  group.  We  believe  that  this  a  reasonable  approach 
whenever  all  of  the  threats  are  in  the  same  general  direction,  but  we  can  give  no 
guarantee  that  it  will  work  in  all  cases. 

3.  The  Bottom  Line 

In  the  end,  a  good  choice  made  quickly  is  often  better  than  the  perfect 
choice  that  takes  too  long.  There  is  no  way  to  accurately  estimate  the  amount  of 
time  between  your  perception  of  the  threat  and  when  it  is  able  to  effectively 
engage  you.  With  modern  weapon  systems,  the  life  expectancy  of  a  fully 
exposed  target  is  very  short.  The  only  prudent  course  of  action  is  to  assume  that 
you  have  no  time  available  and  make  the  initial  decision  as  quickly  as  possible. 
After  you  make  your  initial  decision  and  you  have  some  cover,  you  can  take  the 
time  to  look  for  better  locations. 
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D.  FINDING  COVER  IN  COMPUTER  SIMULATIONS 

1.  Checking  Line  of  Sight 

Most  simulated  environments  have  some  sort  of  line  of  sight  checking  built 
into  the  system.  While  we  call  it  a  “line  of  sight"  check,  we  are  actually 
determining  if  a  line  drawn  between  any  two  points  in  the  simulated  environment 
intersects  anything.  One  of  most  common  uses  for  this  check  is  to  determine  if 
one  entity  can  see  another  one  (thus  the  name),  but  programmers  also  use  it  in  a 
wide  variety  of  applications  including  navigation  and  determining  projectile  impact 
points. 

The  results  returned  by  line-of-sight  functions  vary  greatly  from  program  to 
program.  It  is  important  when  designing  your  system  to  know  all  of  the 
information  that  it  can  provide  and  then  use  that  to  your  advantage  when 
developing  your  cover  algorithms.  Some  of  the  information  returned  may 
include: 

•  True  /  False  answer  indicating  if  an  object  was  intersected 

•  Coordinates  to  the  point  of  intersection 

•  Surface  normal  of  the  point  of  intersection 

•  A  reference  to  the  object  intersected 

Some  systems  go  even  further  and  offer  a  set  of  functions  that  trade 
information  for  speed:  A  fast  trace  that  just  returns  “True”  or  “False”,  a  medium 
speed  trace  that  returns  information  on  the  first  intersection,  and  a  slow  trace  that 
returns  information  on  all  intersections  along  the  line  segment. 

Checking  line  of  sight  requires  a  significant  amount  of  computational  effort 
on  the  part  of  the  computer  and  programmers  always  try  to  minimize  the  use  of 
line  of  sight  checks  in  real-time  simulations.  The  process  normally  involves 
several  dot  products,  cross  products,  and  comparisons  for  each  polygon  tested. 
Programmers  use  various  culling  algorithms  to  limit  the  number  of  polygons  in 
the  environment  that  are  actually  tested.  However,  typical  environments  can  be 
composed  of  several  million  of  triangles,  which  can  be  difficult  to  process  quickly. 

One  problem  with  most  line  of  sight  checks  is  that  they  do  not  accurately 

determine  if  an  object  can  be  seen.  The  location  of  an  object  in  an  environment 
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is  most  often  recorded  as  a  three-number  vector.  If  we  check  line  of  sight  to  this 
location  and  the  result  says  that  we  can  see  it,  then  we  can  definitely  see  the 
specific  point  on  the  object.  However,  if  the  result  says  that  the  line  of  sight  is 
blocked,  this  does  not  necessarily  mean  that  we  cannot  see  another  part  of  the 
object.  Other  portions  of  the  object  may  be  plainly  visible. 

Additional  line  traces  can  increase  the  probability  that  the  object  is 
completely  out  of  sight,  but  this  technique  is  still  prone  to  error  and  may  not  be 
computationally  efficient.  For  example,  you  could  use  the  four  corners  of  a 
bounding  box  around  the  object  to  perform  additional  checks.  If  all  of  the  checks 
say  that  line  of  sight  is  blocked,  then  you  can  be  reasonably  sure  that  the  position 
gives  the  object  cover.  Then  you  might  have  the  opposite  problem.  The  object 
could  be  completely  in  cover,  but  a  corner  of  the  bounding  box  sticking  out  in  the 
open.  In  this  case,  the  function  would  report  that  line  of  sight  existed  to  the 
object,  when  it  really  does  not.  On  top  of  this,  you  have  just  increased  your 
requirement  for  line  of  sight  checks  by  five  times;  one  for  the  location  of  the 
object  plus  four  more  for  the  corners  of  the  bounding  box. 

Even  with  all  of  their  problems,  line-of-sight  checks  provide  a  useful 
approximation  for  determining  if  a  threat  can  see  a  target.  It  may  be  the  case 
that  the  only  way  to  make  a  more  accurate  system  would  be  to  implement  some 
form  of  a  computer  vision  system.  While  line-of-sight  checks  are  computationally 
expensive,  they  are  much  less  expensive  than  even  primitive  computer  vision 
systems.  They  key  is  to  tune  your  system  to  get  a  good  balance  between 
computational  performance  and  task  performance. 

2.  A  Computer  Agent’s  View  of  the  World 

An  agent  views  the  world  through  a  set  of  sensors.  By  combining  this 
information  with  internal  logic,  perception,  and  previous  knowledge,  it  creates  an 
internal  representation  of  the  world.  Generally,  this  is  not  a  complete 
representation  of  the  world  due  to  the  amount  of  storage  space  required.  It  is 
debatable  what  level  of  representation  humans  retain  in  their  memories.  Often 
the  agent  processes  the  detailed  information  and  keeps  a  summarized  version 

on  hand.  It  only  keeps  enough  information  on  hand  to  complete  its  task. 
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For  an  example  of  what  information  is  available  to  a  typical  computer 
game  agent  we  will  use  the  computer  game  Unreal  Tournament  [22],  The 
computer  agents  that  you  compete  against  in  the  single  player  version  of  Unreal 
Tournament  are  commonly  called  “Bots”.  Unreal  Bots  are  able  to  navigate 
through  their  world  and  interact  with  it  in  all  the  same  ways  that  players  can.  The 
Bots  provide  challenging  game-play  for  players  and  exhibit  a  range  of  behaviors 
that  are  very  similar  in  some  ways  to  that  of  human  players  in  multi-player 
games. 

The  behavior  of  Unreal  Bots  is  controlled  by  state  code  [21].  The  code 
that  controls  the  Bot  is  separated  into  sections  called  states.  Execution 
continues  inside  of  the  current  section  until  something  happens  that  causes 
execution  to  jump  to  another  state.  Some  functions  may  be  redefined  inside  of 
certain  states  so  that  their  execution  becomes  state-dependant.  That  is,  the 
current  state  of  the  Bot  determines  which  version  of  the  function  is  executed 
when  it  is  called.  This  produces  behavior  that  depends  on  the  current  state  of 
the  Bot  as  well  as  the  actual  stimulus  that  it  receives. 

The  Bot  starts  in  a  default  state  that  ensures  everything  is  initialized 
correctly  and  then  proceeds  into  other  states  based  on  its  goals,  perceptions, 
and  state  transition  code.  For  example  a  Bot  could  start  in  a  “Hunting”  state 
where  it  would  travel  around  the  map  looking  for  players  to  fight.  Once  it  sees  a 
player,  it  will  decide  whether  it  should  attack  the  player  or  flee.  If  it  decides  to 
attack,  it  will  move  to  one  of  its  “Attack”  states  and  engage  the  player.  If  the 
player  runs  away  the  Bot  will  chase  them.  If  it  takes  too  much  damage,  it  may 
decide  that  it  needs  to  run  away  and  it  will  enter  a  “Flee”  state.  In  the  “Flee”  state 
it  will  move  away  from  a  player  and  attempt  to  find  objects  that  it  can  pick  up  to 
heal  itself.  This  seems  like  a  robust  set  of  behaviors,  but  the  agent  produces 
these  behaviors  with  a  bare  minimum  of  information  about  the  actual 
environment  around  it. 

An  Unreal  Agent  has  no  idea  what  the  world  around  it  actually  looks  like. 
It  has  no  information  about  the  size  or  shape  of  the  rooms.  It  does  not  know 
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anything  about  the  vast  majority  of  the  objects  in  the  environment.  When  it 
needs  something  like  a  First  Aid  packet,  ammunition,  or  a  gun  it  queries  the 
game  engine  and  stores  the  result. 

Unreal  Bots  navigate  through  their  world  by  using  a  waypoint  graph. 
Waypoints  are  placed  throughout  the  environment  by  level  designers.  The 
waypoints  are  connected  by  links  that  tell  the  system  which  waypoints  can  be 
reached  from  which  other  waypoints.  The  links  between  waypoints  are 
directional.  For  two  waypoints  to  be  connected  by  a  link,  they  must  be  within 
direct  line  of  sight  of  each  other  and  a  Bot  must  be  able  to  travel  directly  between 
them.  The  series  of  waypoints  and  the  links  between  them  form  a  navigational 
graph  that  allows  the  Bot  to  move  around  the  environment.  However,  the  Bot 
does  not  keep  even  this  information  internally.  The  game  engine  keeps  track  of 
the  actual  waypoint  graph.  When  the  Bot  wants  to  go  somewhere,  it  sends  a 
request  to  the  game  engine,  which  in  turn  tells  it  which  direction  to  move. 

An  Unreal  Bot  knows  about  the  player  through  a  reference.  When  a 
player  comes  into  line  of  sight  of  a  Bot  the  game  engine  sends  the  Bot  a 
“seePlayer”  message  that  includes  a  reference  to  the  player.  The  Bot  can  then 
use  this  reference  to  gather  additional  information  about  the  player,  such  as  their 
position,  health,  and  weapons  they  carry.  The  Bot  does  not  retrieve  any  of  this 
information  until  it  is  needed.  When  the  player  moves  out  of  line  of  sight  the  Bot 
receives  another  message  telling  it  that  it  can  no  longer  see  the  player. 

In  order  to  take  cover  the  Bot  will  need  more  information  about  the 
environment. 

3.  Penetration  of  Objects 

Most  computer  simulations  do  not  accurately  represent  the  penetration  of 
objects  by  projectiles.  Most  often  whether  an  object  stops  weapons  fire  or  not  is 
a  True/False  Boolean  value  stored  somewhere  with  the  object.  In  real  life  the 
penetration  of  an  object  by  a  projectile  is  affected  by  a  large  number  of  factors 
including  the  material  the  object  is  composed  of,  the  thickness  of  the  material, 
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the  type  of  projectile,  and  the  angle  of  incidence.  Whether  or  not  an  object  can 
be  penetrated  by  a  weapon  has  a  direct  impact  on  the  quality  of  cover  it  provides. 

Different  materials  behave  differently  when  struck  by  a  projectile.  Soft 
materials  may  absorb  the  energy  of  the  projectile,  while  hard  materials  may 
reflect  it.  Some  materials  may  deform  when  struck  while  others  may  not.  A 
brittle  material  may  shatter  when  struck.  These  all  can  have  an  effect  on  the 
resistance  offered  by  the  material  and  the  effects  of  repeated  shots  against  the 
material. 

The  type  of  projectile  has  a  major  impact  on  whether  or  not  it  penetrates 
an  object.  An  object  that  stops  regular  bullets  well  may  offer  little  protection 
against  armor  piercing  rounds  that  are  designed  to  have  greater  penetration. 
Against  exotic  weapons  such  as  lasers,  some  materials  may  absorb  the  energy 
while  others  offer  no  protection  at  all.  Blast-effect  weapons  can  be  even  more 
problematic  as  their  energy  spreads  over  the  entire  surface  of  the  object  instead 
of  a  discrete  point. 

Once  you  determine  if  a  round  penetrates  an  object  or  not,  you  still  have 
to  determine  what  happens  to  the  round.  If  the  round  does  not  penetrate  the 
object,  it  can  either  be  absorbed  or  reflected.  If  it  does  penetrate  the  object  then 
its  characteristics  need  to  be  modified  to  account  for  the  energy  lost  during 
penetration  as  well  as  any  changes  in  its  flight  path.  Since  objects  in  the  vast 
majority  of  simulations  are  not  actually  solid,  one  method  that  has  been 
employed  is  to  re-spawn  the  projectile.  The  original  projectile  is  destroyed  at  the 
front  surface  of  the  object  and  a  new  projectile  is  created  on  the  far  side  of  the 
object  with  appropriately  modified  properties. 
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III.  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  discusses  how  military  simulations  and  computer  games 
have  commonly  addressed  the  problem  of  finding  cover.  We  also  discuss  some 
of  the  limitations  of  their  solutions  and  why  we  need  a  better  solution. 

B.  MILITARY  SIMULATIONS 

1.  Terrain  Annotation 

Many  older  military  simulations  calculated  cover  based  on  the  terrain  that 
the  target  occupies.  For  example,  a  unit  in  a  section  of  the  map  with  woods 
would  have  more  cover  than  a  unit  that  was  in  the  open.  There  is  no  actual 
attempt  to  draw  line  of  sight,  because  elevation  data  is  not  included  in  the  maps. 
However,  because  these  simulations  aggregate  individual  combatants  together 
into  units  this  makes  sense.  It  is  impossible  to  do  detailed  line  of  sight  checks 
when  the  simulation  does  not  track  the  exact  location  of  individual  combatants. 

As  military  simulations  have  developed,  they  have  become  more  and 
more  detailed.  A  greater  level  of  detail  gives  them  the  potential  to  be  more 
accurate  and  provide  us  with  more  information  that  is  useful.  Many  of  the  current 
military  simulations  use  terrain  elevation  data  and  consider  this  when  determining 
line  of  sight.  In  these  systems,  the  cover  that  a  unit  has  is  determined  by  a 
combination  of  line  of  sight  (as  determined  by  the  terrain  elevation  data)  and  the 
type  of  terrain  that  the  unit  currently  occupies. 

At  the  far  end  of  this  ever-increasing  level  of  detail  are  the  agent-based 
simulations.  In  these  simulations,  combatants  are  required  to  think  for 
themselves  and  react  to  their  current  surroundings.  Units  are  modeled  all  the 
way  down  to  the  individual.  In  order  to  accurately  model  how  an  individual 
behaves  on  the  battlefield,  they  will  need  to  be  able  to  take  cover  in  highly 
detailed  environments. 

2.  Terrain  Cell  Line  of  Sight 

An  interesting  modification  of  terrain  annotation  is  based  on  line  of  sight  to 

the  cells  instead  of  just  the  underlying  terrain.  Horn  and  Baxter  published  a 
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paper  describing  their  development  of  a  tool  that  can  be  used  to  automatically 
plan  tank  squadron  assaults  that  uses  this  technique  [13]. 

Their  program  preprocessed  the  map  in  order  to  find  the  cover  locations. 
The  program  samples  the  map  data  every  100  meters  to  form  depth  map  of  the 
area  of  operations.  The  user,  based  on  the  best  current  intelligence  on  their 
positions,  assigns  the  enemy  an  area  on  the  map.  The  user  places  the  friendly 
forces  their  initial  positions  and  then  the  program  analyzes  the  situation.  Cover  is 
used  in  both  directions  during  this  process:  it  determines  both  what  the  enemy 
cannot  see  and  which  positions  provide  good  visibility  of  the  enemy  area. 

The  program  determines  the  cover  that  each  location  provides  by 
calculating  how  much  of  the  enemy  area  can  draw  line  of  sight  to  that  location. 
Only  the  terrain  elevation  data  is  taken  into  account;  information  on  trees, 
buildings,  and  other  objects  are  not  considered.  Line  of  sight  is  drawn  from  each 
location  in  the  enemy  area  back  to  the  location  we  are  considering.  The  fewer 
places  that  can  draw  line  of  sight  to  the  location,  the  better  the  cover  it  provides. 

While  this  is  an  effective  method  for  determining  cover,  it  does  not  suit  the 
purposes  of  this  paper.  At  one  measurement  per  100  meters  of  map  area,  it  is 
too  low  detail  for  our  use.  Trees,  building,  and  other  detailed  objects  are  also  not 
considered.  Finally,  this  is  not  a  “run-time”  model.  It  is  designed  to  preprocess 
the  map,  not  to  calculate  cover  while  the  simulation  is  in  progress.  Processing 
line  of  sight  from  every  position  on  the  map  to  every  other  position  on  the  map  is 
very  calculation  intensive,  which  may  make  it  undesirable  for  use  in  simulations 
that  have  to  function  in  real  time. 

C.  COMPUTER  GAME  Al 

1.  Scripting  and  Channeling 

Many  of  the  methods  used  by  computer  game  developers  for  making  their 
agents  use  cover  could  be  collectively  called  “scripting  and  channeling”. 
Scripting  is  when  an  agent  is  given  a  predefined  set  of  actions  to  follow,  like  a 
movie  script.  Forcing  a  player  take  a  certain  path  through  the  level  is  called  what 
we  call  channeling. 
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Scripting  and  channeling  are  a  form  of  preprocessing  that  is  totally 
dependent  on  the  level  designer’s  ability  to  find  cover.  The  steps  vary,  but  in 
general  the  level  designer  first  plans  what  type  of  encounter,  they  wish  to  have. 
Then  they  pick  a  location  for  the  encounter  in  the  level.  The  level  designer  then 
places  objects  in  the  level  that  restrict  the  movement  of  the  player  into  a  channel 
toward  the  location  of  the  encounter.  This  determines  the  direction  from  which 
the  agents  will  need  to  take  cover.  The  level  designer  can  then  find  good  cover 
locations  and  write  a  script  telling  the  agents  how  and  when  to  use  them. 

Used  together,  scripting  and  channeling  can  make  computer-controlled 
agents  appear  to  be  very  good  at  finding  and  using  cover.  In  the  computer  game 
Medal  of  Honor:  Allied  Assault  by  EA  Games  there  are  examples  where 
enemies  fire  around  the  corners  of  walls  and  even  kick  over  tables  to  hide 
behind.  This  makes  them  seem  extremely  capable  of  finding  cover,  but  in 
actuality,  the  situation  is  very  tightly  controlled.  If  you  play  the  same  level  several 
times  you  will  be  forced  into  the  same  situation  and  the  agents  will  do  the  same 
thing  every  time.  It  quickly  becomes  apparent  that  they  are  not  really  thinking 
about  the  terrain. 

While  scripting  and  channeling  work  perfectly  well  in  most  games,  they 
completely  fall  apart  in  any  large,  unconstrained  environment.  In  an 
unconstrained,  free-play  environment  it  will  be  impossible  to  tell  which  direction 
the  enemy  will  be  coming  from  so  choosing  cover  locations  becomes  impossible. 
Most  computer  game  levels  are  also  very  small  compared  to  any  military 
simulation.  At  some  point  it  becomes  too  large  for  the  level  designer  to  consider 
every  locations’  cover  value. 

2.  Waypoint  Annotation 

One  of  the  most  popular  current  approaches  to  solving  almost  any 

problem  dealing  with  interaction  between  the  agent  and  its  environment  is  to  use 

waypoints.  Waypoint  graphs  were  developed  as  a  means  of  allowing  the  agents 

to  easily  navigate  through  a  level.  A  series  of  points  are  placed  throughout  the 

map  anywhere  the  agent  may  need  to  go.  All  the  points  are  connected  to  the 

points  around  them  by  links.  In  order  to  be  linked,  two  points  must  have  direct 
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line  of  sight  to  each  other.  Once  this  is  done,  instead  of  doing  costly  navigation 
processing  of  the  environment,  the  agents  simply  move  around  on  the  graph  like 
a  car  following  a  road. 

Game  developers  use  the  waypoint  graph  for  more  than  just  navigation. 
By  storing  additional  information  at  the  nodes  on  the  waypoint  graph,  they  can 
preprocess  the  information  and  store  it  at  the  node.  For  instance,  instead  of 
having  an  agent  calculate  if  it  can  jump  across  a  small  gap  during  the  game,  you 
can  use  waypoints  to  store  the  information.  Determine  where  the  agent  can 
make  the  jump  and  place  a  waypoints  at  the  take  off  and  landing  points.  Store 
some  additional  information  at  the  nodes  that  tells  the  agent  it  is  supposed  to 
jump  when  it  gets  to  the  nodes.  Now  when  the  agent  needs  to  find  out  if  it  can 
make  the  jump,  it  queries  the  waypoint  graph  and  the  information  is  right  there  for 
it. 

Waypoints  can  also  be  used  as  sensor  points  to  gather  information  about 
the  environment.  The  environment  around  them  can  be  sampled  and  the 
information  stored  with  the  waypoint.  This  information  is  then  readily  available 
for  the  agent  to  use  in  deciding  where  to  go.  The  waypoints  can  store  a  wide 
variety  of  information  including  local  lighting  levels,  accessibility,  and  line  of  sight. 

When  we  attended  the  2003  Game  Developers  Conference,  we  talked  to 
many  game  designers  about  the  problem  of  finding  cover.  Every  single  one  of 
them  that  we  talked  to  immediately  proposed  using  waypoints  as  a  solution  to  the 
problem.  In  a  way,  this  makes  perfect  sense.  The  use  of  waypoints  is  well 

defined  and  easy  to  code.  It  also  takes  very  little  processing  power  during 

execution,  which  is  very  important  to  maintain  high  frame  rates.  In  this  case,  the 
ability  of  the  agent  to  find  good  cover  locations  becomes  almost  totally 

dependent  on  the  level  designer’s  ability  to  place  the  waypoints  in  logical 

locations.  Unfortunately,  no  matter  how  carefully  the  level  designer  chooses 
points  for  cover,  all  points  on  the  level  may  provide  cover  in  some  circumstance. 

One  very  well  developed  example  of  using  waypoints  to  find  cover  is  a 
paper  by  Van  der  Sterren  about  analyzing  terrain  to  pick  sniper  locations  [24], 
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Van  der  Sterren’s  algorithm  functions  during  execution  and  processes  the 
waypoint  graph  against  ten  separate  criteria  to  determine  the  best  current  sniping 
position.  Cover  is  one  of  the  considerations  in  choosing  a  waypoint  as  a  sniping 
position.  Cover  in  Van  der  Sterren’s  algorithm  is  calculated  waypoint  to 
waypoint.  A  position  is  considered  to  provide  cover  if  it  has  an  adjacent  waypoint 
or  waypoints  that  are  out  of  line  of  sight  from  the  waypoints  in  the  target  area. 

This  algorithm  has  two  main  benefits:  it  is  fast  and  it  is  adaptable  to  the 
current  situation  in  the  game.  The  algorithm  is  kept  fast  by  minimizing  the 
number  of  necessary  line  traces.  The  set  of  all  waypoints  can  be  easily  culled 
down  to  a  set  of  interest  and  line  traces  are  minimized  because  they  are  only 
done  from  waypoint  to  waypoint.  The  algorithm  is  able  to  adapt  to  the  current 
situation  by  executing  during  run-time. 

Even  though  Van  der  Sterrne’s  algorithm  executes  during  run-time,  it  still 
requires  significant  amounts  of  pre-computation.  In  the  example  that  he 
provides,  he  uses  around  480  waypoints  on  a  small  level  that  appears  to  be  less 
than  500  meters  square.  A  level  designer  must  place  each  of  these  waypoints. 
Because  of  this,  the  performance  of  the  algorithm  will  be  highly  dependent  on  the 
density  of  the  waypoints  and  the  quality  of  their  placement. 

One  problem  that  waypoint-based  cover  algorithms  have  in  dynamic 
environments  is  that  they  are  static.  Checking  the  same  location  every  time 
means  that  they  will  not  always  offer  the  best  solution.  Consider  Figure  1  below. 
The  circle  represent  waypoints  and  the  dashed  lines  the  graph  between  them.  A 
large  object  in  the  center  of  the  room  provides  cover  to  everything  on  the  other 
side  of  it.  This  area  of  cover  is  represented  by  the  cross-hatched  area.  If  the 
agent  searches  the  waypoint  graph  it  will  find  that  there  are  two  waypoints  that 
are  in  cover.  I  could  choose  either  of  these  as  places  to  move  to  and  be  in  cover 
from  the  threat.  However,  neither  of  them  offers  an  optimal  solution.  The  agent 
can  get  into  cover  faster  by  moving  directly  to  a  point  inside  the  cover  that  is  not 
part  of  the  waypoint  graph. 
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Figure  1 .  Using  Waypoints  Can  Miss  Cover  Locations 

Another  problem  with  using  waypoint  graphs  is  that  they  cannot  handle 
dynamic  terrain.  The  level  designer  positions  the  waypoints  long  before  the 
game  begins.  The  placement  of  each  waypoint  is  carefully  considered,  but  there 
is  no  way  to  anticipate  changes  that  may  occur  in  a  dynamic  environment.  As 
the  terrain  changes,  cover  opportunities  may  be  missed. 

Consider  Figure  2  below.  The  left  hand  side  shows  the  initial  situation. 
The  agent  has  taken  cover  at  the  center  waypoint  based  on  line  of  sight  checks 
from  the  threat  to  the  waypoints.  The  right  had  side  shows  the  situation  after  an 
explosion  that  has  moved  the  large  object.  None  of  the  waypoints  are  now  in 
cover  and  the  object  even  blocks  part  of  the  waypoint  graph.  Even  though  cover 
is  still  available,  the  agent  is  unable  to  find  it  by  using  the  waypoint  graph. 
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Figure  2.  Waypoint  Methods  May  Not  Handle  Dynamic  Environments 
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IV.  CONCEPTUAL  MODELS 


A.  INTRODUCTION 

This  chapter  discusses  the  three  conceptual  models  that  we  developed  for 
finding  cover  in  dynamic,  three-dimensional  environments.  The  Binary  Space 
Partition  Shadow  Volume  Tree  method  uses  light-source  shading  methods  to  find 
areas  of  cover.  The  Depth  Mapping  method  uses  a  rough  approximation  of 
computer  vision  techniques  to  find  places  where  the  agent  can  potentially  take 
cover.  The  Sensor  Grid  method  places  a  series  of  sensors  around  the  agent  and 
uses  them  to  detect  potential  cover  locations. 

B.  ASSUMPTIONS 

We  made  the  following  assumptions  in  order  to  simplify  the  algorithms  in 
development.  If  needed  it  should  be  possible  to  modify  any  of  the  algorithms  so 
that  any  of  these  assumptions  are  no  longer  necessary. 

1.  We  are  Only  Concerned  About  Taking  Cover  from  Direct  Fire 

This  assumption  allows  us  to  focus  on  one  type  of  cover.  Cover  from 

direct-fire  weapons  is  the  simplest  case  to  analyze  because  we  can  assume  that 
the  projectile  travels  along  a  straight  line  from  the  threat  to  the  target. 

We  can  add  cover  from  indirect-fire  weapons  later  by  determining  likely 
impact  points.  Adding  cover  for  area-of-effect  type  weapons  will  depend  on  the 
behavior  of  the  particular  threat.  Changes  for  cover  from  area-of-effect  type 
weapons  could  involve  signification  changes  in  the  algorithms  if  the  effects  of  the 
weapon  behave  like  a  fluid.  To  accurately  calculate  the  area  of  effect  could 
require  complex  calculations  and  could  also  depend  on  the  geometry  of  the  area 
of  detonation. 

2.  Any  Object  that  Blocks  Line  of  Sight  Provides  Cover 

This  assumption  allows  us  to  avoid  analyzing  material  properties  while 
calculating  cover  locations.  Material  properties  are  often  missing  in  many 
simulations  so  this  information  would  not  be  available.  In  some  simulations,  this 
information  may  be  stored  at  the  object  level.  This  would  require  a  capability  to 
determine  which  object  individual  polygons  belong  to. 
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Even  when  an  object  does  not  provide  cover,  it  may  still  provide 
concealment.  When  cover  is  not  available,  concealment  is  better  than  nothing  at 
all.  Therefore,  while  we  are  focusing  on  finding  cover,  this  assumption  still 
provides  reasonable  behavior  for  our  agent. 

To  design  a  system  where  we  do  not  make  this  assumption  requires  that 
we  consider  the  penetration  of  objects  and  their  value  as  concealment.  Such  a 
system  would  need  a  line-of-sight  algorithm  that  was  able  to  return  every 
intersection  along  the  weapon’s  potential  flight  path.  The  line-of-sight  algorithm 
would  also  need  to  provide  access  to  the  material  properties  of  the  objects 
intersected. 

The  decision  logic  for  an  agent  in  such  a  system  would  need  to  be  much 
more  complicated  also.  In  determining  where  to  move,  the  agent  would  have  to 
weigh  the  value  of  cover  verses  concealment.  It  would  need  to  be  able  to  decide 
between  a  close  position  that  provides  concealment  verses  a  far  position  that 
provides  cover.  It  would  also  need  to  be  able  to  determine  if  an  object  provides 
enough  cover  to  stop  the  threat  the  agent  is  facing. 

A  full  system  that  can  find  both  cover  and  concealment  will  most  likely 
require  separate  algorithms  for  cover  and  concealment.  Cover  and  concealment 
are  fundamentally  different  in  that  concealment  does  not  require  an  intervening 
object.  Since  concealment  involves  anything  that  hinders  the  enemy’s  ability  to 
see  the  agent,  it  involves  as  much  signal  detection  theory  as  it  does  line  of  sight 
algorithms.  Most  cover  algorithms  will  not  be  able  to  handle  cases  where  you 
can  take  concealment  by  “hiding  in  plain  sight”  (e.g.  in  shadows  or  through 
camouflage  where  there  are  no  intervening  objects  between  the  threat  and  the 
target). 

3.  There  is  Only  One  Enemy 

This  assumption  allows  us  to  explore  the  simplest  case  where  there  is 
only  one  threat.  We  need  to  be  able  to  handle  one  enemy  before  being  able  to 
handle  multiple  threats. 
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There  are  several  ways  that  an  algorithm  could  be  implemented  to 
consider  multiple  threats.  The  most  straightforward  option  is  to  calculate  cover 
for  every  threat  individually  and  then  combine  the  results.  However,  this  option 
can  be  very  computationally  expensive.  Another  option  is  take  some  subset  of 
the  enemy  and  calculate  cover  based  on  their  locations.  This  option  is  less 
expensive  computationally,  but  its  performance  is  highly  dependent  on  the  actual 
arrangement  of  the  enemy  forces.  A  good,  general-purpose  method  of  handling 
an  arbitrary  number  of  threats  from  several  different  directions  will  require 
significant  effort  to  develop  properly. 

4.  The  Agent  Taking  Cover  Knows  the  Location  of  the  Enemy 

This  assumption  allows  us  to  focus  on  finding  cover  instead  of  determining 

the  agent’s  perception  of  threats. 

To  develop  an  algorithm  where  the  location  of  the  enemy  may  not  be 
known  requires  modeling  of  the  agent’s  perception  of  the  enemy’s  location.  If 
there  is  any  information  at  all  the  agent  would  have  to  be  able  to  hypothesize  the 
location  of  the  threat  in  order  to  decide  where  to  take  cover.  If  there  is  no 
information  at  all,  then  the  situation  is  almost  reversed.  In  this  case,  the  agent 
will  want  to  find  the  cover  location  that  provides  the  best  protection  from  the 
widest  area. 

5.  The  Agent  Taking  Cover  Knows  What  the  Enemy  Can  See 

This  assumption  reduces  our  computational  complexity  by  avoiding 
calculation  of  natural  biases  in  human  exocentric  perception.  Doing  one 
calculation  with  perfect  knowledge  at  the  beginning  helps  us  avoid  additional 
processing  requirements. 

In  order  to  implement  a  system  with  imperfect  knowledge  of  what  the 
enemy  can  see  we  would  need  to  model  the  natural  biases  in  human  exocentric 
perception.  In  real  life,  we  compensate  for  these  biases  by  constant  reevaluation 
of  the  cover  location  as  we  move  toward  and  into  the  position.  Accurately 
replicating  this  in  an  agent  would  greatly  increase  the  computational  cost  of 
running  any  cover  algorithms. 
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6.  The  Agent  Taking  Cover  has  Perfect  Knowledge  of  the  Area  of 
Interest  Around  It 

This  assumption  allows  us  to  find  cover  without  maintaining  an  internal 
representation  inside  the  agent  of  the  surrounding  area.  This  saves  memory 
space,  the  processing  power  that  would  be  required  to  build  the  internal 
representation,  and  the  processing  power  for  hypothesizing  about  areas  where 
the  agent  only  has  partial  information. 

To  build  an  algorithm  where  the  agent  had  imperfect  knowledge  of  the 
area  of  interest  around  it  would  require  extensive  sensor  modeling,  a  detailed 
internal  representation  of  the  surrounding  area,  an  ability  for  the  agent  to 
hypothesize  about  unseen  areas,  and  a  conflict-resolution  capability. 

The  agent  would  need  to  be  able  to  process  detailed  information  on  the 
portions  of  the  area  that  it  had  observed  and  build  it  into  a  detailed  internal 
representation.  The  cover  calculations  would  then  be  run  on  the  internal  model 
of  the  world  instead  of  the  actual  environment.  All  of  the  algorithms  presented  in 
this  paper  require  detailed  line  of  sight  information.  The  only  way  to  accurately 
process  the  same  information  inside  of  the  agent’s  perception  would  require  an 
almost  perfect  copy  of  the  environment  down  to  the  polygon  level.  The  memory 
requirements  for  this  would  be  enormous. 

The  agent  would  also  need  to  be  able  to  hypothesize  about  areas  that  it 
has  not  directly  observed.  Given  that  the  agent  sees  a  box  on  the  floor  from  one 
angle,  it  would  need  to  be  able  to  determine  whether  it  thinks  that  the 
unobserved  side  of  the  box  would  be  a  suitable  cover  location  or  not. 

The  agent  would  also  need  to  have  decision  logic  to  deal  with  conflicts  in 
its  internal  representation  and  the  actual  environment.  Continuing  the  example  in 
the  paragraph  above,  suppose  that  the  agent  has  decided  to  take  cover  behind 
the  box.  It  moves  around  the  box  to  find  that  it  cannot  get  behind  the  box  for 
some  reason.  The  information  that  it  based  its  decision  on  has  now  changed. 
The  agent  must  be  able  to  deal  with  these  situations. 
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C.  THEORY 

This  section  deals  with  the  theory  we  developed  for  guiding  the 
development  of  our  algorithms.  When  searching  for  cover  in  virtual 
environments,  we  must  ask  three  basic  questions: 

•  Where  is  there  cover? 

•  Where  can  I  reach? 

•  Where  can  I  stand? 

Covered  areas  offer  protection  from  direct  fire.  As  stated  in  the 
assumptions  section  we  will  consider  any  area  that  is  out  of  direct  line  of  sight 
from  the  threat  to  provide  cover. 

Reachable  areas  are  places  that  I  can  move  to.  Some  path  must  exist 
that  the  agent  can  use  to  reach  the  location.  A  cover  location  that  we  cannot 
reach  does  us  no  good. 

Standable  areas  are  places  where  the  slope  of  the  terrain  and  the 
composition  of  the  surface  material  allow  us  to  stand,  kneel,  or  lay  prone.  This  is 
important  because  not  all  reachable  areas  are  suitable  as  places  where  we  can 
stop  and  take  cover.  You  might  be  able  to  get  into  a  place  behind  cover  by 
jumping,  but  there  may  not  be  suitable  surface  there  that  allows  you  to  remain  in 
that  position. 

What  we  are  looking  for  is  the  intersection  of  these  three  areas:  Covered 
Reachable,  and  Standable.  Since  there  are  many  methods  currently  available 
for  finding  the  Reachable  and  Standable  areas,  we  have  focused  our  algorithms 
on  finding  Covered  areas.  However,  each  algorithm  presented  in  the  following 
sections  will  detail  any  advantages  or  disadvantages  that  it  offers  in  finding  the 
Reachable  and  Standable  areas. 

D.  BINARY  SPACE  PARTITION  SHADOW  VOLUME  TREES 

1.  Definition 

a.  BSP  Trees 

A  Binary  Space  Partition  tree  (or  BSP  tree)  is  a  hierarchical 
subdivision  of  an  n  dimensional  space  into  homogeneous  regions  [3],  Fuchs, 
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Kedem,  and  Naylor  developed  BSP  trees  in  1979-1980  as  a  way  of  determining 
visibility  priority  in  three-dimensional  scenes  [10][1 1],  Since  then  they  have  been 
used  for  a  variety  of  applications  including  collision  detection,  ray  tracing 
acceleration,  partitioning  of  polygons  into  convex  sub-polygons,  and  shadow 
generation  [3], 

BSP  Trees  use  n-1  dimensional  shapes  to  partition  an  n 
dimensional  space  into  two  convex  subspaces.  Each  subspace  can  be 
partitioned  into  two  more  subspaces  until  the  scene  is  completely  partitioned  into 
elemental,  convex  subspaces.  All  of  the  information  about  the  partitioning  is 
stored  in  the  structure  of  the  binary  tree.  Each  node  contains  information  on  the 
n-1  dimensional  shape  used  for  the  partitioning.  Each  node  also  has  a  front  and 
a  back  leaf.  The  binary  structure  of  the  tree  allows  for  efficient  traversal  and 
quick  information  retrieval. 

The  BSP  tree  is  built  by  adding  elements  from  the  scene  one  at  a 
time  and  placing  them  into  the  tree  appropriately.  There  are  four  cases  that  each 
element  can  fall  in:  in  front,  behind,  coincident,  and  spanning.  Consider  the 
case  of  a  two-dimensional  area  with  objects  A,  B,  C,  D,  and  E  as  shown  in  Figure 
3.  The  two-dimensional  space  is  partitioned  into  subspaces  by  one-dimensional 
lines.  The  tree  is  started  by  picking  a  root  node  which  in  this  case  is  A.  A  line  is 
created  through  A  partitioning  the  space  into  two  sub-spaces.  One  side  of  the 
partition  is  chosen  to  be  the  in-front  area  (marked  by  a  +  sign)  and  the  other  is 
the  behind  area  (marked  by  a  -  sign).  The  original  information  on  A  is  stored 
inside  the  A  node.  We  add  B  next  and  find  that  it  B  falls  in  the  positive  subspace 
of  A.  B  gets  added  as  a  positive  leaf  node  to  A.  Object  C  is  in  the  negative 
region  of  A  so  it  is  added  as  a  negative  leaf  node  of  A.  When  Object  D  is  added, 
we  find  that  it  is  coincident  with  object  B,  so  its  information  is  stored  in  the  same 
node  where  object  B’s  information  is  stored.  When  object  E  is  added  we  find  that 
it  spans  the  partition  created  by  C.  E  is  split  along  the  partition  into  El  and  E2. 
El  is  added  as  C’s  positive  child  and  E2  is  added  as  C’s  negative  child.  We 
have  now  partitioned  the  entire  space  into  convex  subspaces. 
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Figure  3.  BSP  tree  for  a  two-dimensional  space. 


When  used  in  computer  graphics  BSP  trees  are  very  useful  for 
displaying  static  images.  We  can  use  a  back-to-front,  painters  algorithm  or  a 
front-to-back,  scanline  algorithm  to  render  the  view.  All  of  the  visibility 
information  can  be  quickly  extracted  by  traversing  the  BSP  tree.  Once  we  build 
the  tree,  the  camera  can  be  moved  freely  without  rebuilding  the  tree;  it  only 
requires  that  the  tree  be  traversed  in  a  different  order. 

BSP  trees  have  also  been  developed  for  use  in  dynamic  scenes 
with  moving  objects.  As  objects  move,  their  nodes  are  removed  from  the  tree 
and  reinserted.  Since  the  tree  does  not  have  to  be  completely  rebuilt  for  each 
render,  performance  is  greatly  improved.  Normally  all  of  the  objects  in  the  scene 
are  classified  as  static  or  dynamic.  The  tree  is  built  with  the  static  objects  first 
and  then  the  dynamic  objects  are  add  last.  Adding  the  dynamic  objects  last  puts 
them  in  the  leaf  nodes  of  the  BSP  tree,  which  minimizes  costly  internal  changes 
to  the  tree  structure. 

b.  Shadow  Volumes 

A  shadow  volume  is  a  semi-infinite  volume  that  denotes  an  area 

that  is  blocked  from  a  light  source  [16].  Objects  that  are  inside  this  area  are  in 

shadow.  Objects  that  are  outside  this  area  are  not.  A  shadow  volume  is 

enclosed  by  shadow  planes,  which  are  formed  by  using  the  edge  vertices  of  a 
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polygon  and  a  point  light  source.  The  direction  of  the  normal  of  the  shadow 
plane  determines  which  side  of  the  plane  is  in  shadow  or  out  of  shadow.  To 
create  the  shadow  volume  for  a  polygon,  we  create  a  shadow  plane  for  each 
edge  of  a  polygon  and  then  top  it  off  with  a  plane  through  the  polygon  itself. 
Figure  4  shows  an  example  of  a  shadow  volume. 


Point  Light  Source 


Figure  4.  A  Shadow  Volume 

c.  BSP  Shadow  Volume  Trees 

Chin  and  Feiner  introduced  Shadow  Volume  Binary  Space  Partition 
Trees  (or  SVBSP  Trees)  as  a  means  of  computing  shadows  from  point  light 
sources  in  static  scenes  [6],  SVBSP  trees  use  the  structure  of  the  BSP  tree  to 
create  a  merged  shadow  volume  for  the  scene.  When  each  polygon  is  added  to 
the  SVBSP  tree  the  subspace  is  partitioned  along  the  edges  and  in  the  plane  of 
the  polygon  to  create  the  shadow  volume  for  that  polygon.  In  their  algorithm, 
Chin  and  Feiner  imposed  a  strict,  front  to  back  insertion  of  the  polygons  so  that 
the  faces  of  all  polygons  in  the  SVBSP  tree  were  guaranteed  to  be  lit.  As  more 
polygons  are  added,  the  merged  shadow  volume  evolves.  Due  to  the  special 
nature  of  BSP  trees,  the  camera  can  be  moved  around  the  scene  without  having 
to  recomputed  the  scene. 

Since  their  introduction,  there  have  been  many  improvements  to 

the  basic  BSP  tree  and  SVBSP  algorithms.  Chin  and  Feiner  have  developed 
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methods  to  deal  with  multiple  light  sources  as  well  as  area  light  sources  that 
generate  realistic  umbra  and  penumbra  regions  [5],  Chrysanthou  and  Slater 
developed  a  method  for  building  unordered  SVBSP  trees  that  can  handle 
dynamic  environments  [7],  Their  method  allows  for  the  transformation  of  objects 
in  the  scene  without  entirely  rebuilding  the  SVBSP  tree. 

2.  Concept  Applied  to  Finding  Cover 

If  we  treat  the  threat  as  a  point  light  source,  then  areas  that  are  “in 
shadow”  can  be  considered  to  be  in  cover.  Create  a  SVBSP  tree  of  the  scene 
using  the  threat  as  a  point  or  area  light  source.  The  merged  shadow  volume  of 
the  SVBSP  tree  shows  all  of  the  areas  where  cover  may  be  found. 

One  important  modification  of  the  standard  SVBSP  tree  algorithm  is  to 
build  it  only  using  rear-facing  polygons.  Normally  the  SVBSP  tree  algorithm  only 
considers  polygons  that  are  facing  the  light  source.  Rear  facing  polygons  are  not 
visible  and  cannot  be  lit  so  they  are  culled  early  in  the  process.  If  we  use  the 
forward  facing  polygons  in  building  our  SVBSP  trees,  many  of  the  shadow  areas 
will  be  inside  of  objects  (see  Figure  5  below).  Since  we  cannot  move  there,  it 
does  us  no  good  to  consider  these  areas  as  cover. 


as  cover  inside  shadow  volume 

Figure  5.  Shadow  Volume  Created  Using  Forward-Facing  Polygons 

By  only  using  the  rear-facing  polygons,  we  eliminate  the  inside  of  solid 
objects  from  our  shadow  volume  (see  Figure  6  below).  This  has  the  potential  to 
increase  our  greatly  efficiency  when  attempting  to  find  a  point  in  cover. 
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eliminated  from  shadow  volume 

Figure  6.  Shadow  Volume  Created  Using  Rear-Facing  Polygons 

3.  Steps  in  the  Algorithm 

Our  algorithm  for  finding  cover  using  SVBSP  trees  has  the  following  steps: 

•  Determine  the  location  of  the  threat. 

•  Create  a  view  frustrum  from  the  threat,  centered  on  your  location, 
which  is  large  enough  to  encompass  the  area  where  you  want  to 
find  cover. 

•  Build  the  SVBSP  tree  using  all  of  the  polygons  in  the  scene  graph 
culling  those  that  are  outside  of  the  view  frustrum  and  those  that 
are  forward  facing. 

•  Find  the  intersection  of  the  shadow  volume  and  the  standable 
surfaces. 

•  Determine  which  surfaces  in  this  area  are  reachable. 

•  Choose  a  reachable  point  and  move  there. 

4.  Benefits 

Using  SVBSP  trees  to  find  cover  has  two  main  benefits:  it  finds  areas  of 
cover  and  it  uses  no  approximations  in  finding  cover. 

By  finding  areas  of  cover  instead  of  cover  points,  it  gives  the  agent  more 
complete  information  about  its  surroundings.  The  agent  can  plan  movement 
routes  that  stay  inside  of  the  covered  area.  The  agent  can  also  identify  broken 
areas  of  cover  and  large  uniform  areas  of  cover,  which  could  be  part  of  its 
decision  criteria  in  choosing  an  exact  destination  for  its  move. 

SVBSP  tree  use  no  approximations  when  determining  cover.  Since  it 
uses  the  exact  polygon  model  for  the  scene  and  mathematical  equations  for  the 
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shadow  planes  there  are  no  approximations  that  need  to  be  made  when 
determining  the  areas  that  are  out  of  line  of  sight  from  the  threat. 

5.  Problems 

BSP  trees  require  a  large  amount  of  computational  power  and  may  be  too 
slow  for  some  applications.  According  to  the  BSP  Tree  Frequently  Asked 
Questions  section  of  the  OpenGL  website,  complexity  (time  and  space)  for  BSP 
trees  is  0(n2)  upper  bound  and  O(n)  expected  for  n  polygons  [3],  With  the  ever- 
increasing  polygon  counts  in  three-dimensional  environments,  the  processing 
power  may  not  be  available  to  make  the  SVBSP  tree  algorithm  feasible  for  use  in 
real-time  applications. 

Another  problem  with  the  SVBSP  tree  method  for  finding  cover  is  that  it 
can  be  very  difficult  to  determine  if  your  agent  will  fit  behind  a  piece  of  cover  and 
be  totally  hidden.  If  a  model  uses  lots  of  large  polygons  the  shadow  volumes  will 
also  be  large  and  your  agent  can  fit  entirely  inside  of  one.  However,  say  you 
have  a  rock  which  has  100  rearward  facing  polygons  from  the  threats  location. 
Each  polygon  will  create  its  own  shadow  volume.  None  of  them  alone  may  be 
large  enough  for  your  agent  to  fit  in,  but  collectively  they  provide  plenty  of  room. 
There  must  be  some  method  for  handling  this  situation. 

While  we  have  listed  finding  areas  of  cover  as  a  benefit  for  this  method,  it 
can  also  be  a  problem  when  trying  to  find  a  movement  destination  for  the  agent. 
An  area  defined  by  several  planes  essentially  has  an  infinite  number  of  locations 
inside.  Choose  any  two  points  inside  the  area  and  you  can  produce  a  point  in 
between  them.  So  you  must  develop  a  method  for  choosing  a  single  point  as  a 
destination  inside  of  the  cover  area  once  it  is  computed. 

E.  DEPTH  MAPPING 

1.  Definition 

Depth  Mapping  is  a  means  of  representing  n  dimensional  data  in  an  n-1 
dimensional  form.  Each  element  in  the  n-1  dimensional  format  holds  the  data  on 
the  nth  dimension.  As  the  name  implies,  this  is  normally  depth  or  distance 
information.  For  example  a  depth  map  of  a  three  dimensional  scene  from  a 

specific  viewpoint  would  be  a  two  dimensional  grid  with  numbers  in  each  square 
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representing  the  distance  from  the  viewpoint  to  the  first  object  struck  in  that 
square. 

2.  Concept  Applied  to  Finding  Cover 

Depth  mapping  is  similar  to  computer  vision  techniques  in  that  it 
transforms  the  scene  into  a  numerical  representation  of  what  the  threat  can  see 
and  processes  the  information.  It  produces  a  reduced -detail  resolution 
approximation  of  the  depth  of  objects  in  the  scene  from  the  threat’s  point  of  view. 
We  must  then  process  the  information  stored  in  the  depth  buffer  to  find  cover  in 
the  scene. 

Depth  mapping  creates  a  layer  of  information  on  the  scene.  This  is  very 
similar  to  shadow  mapping  in  that  only  the  information  on  the  closest  object  to 
the  threat  is  stored  in  each  cell  of  the  grid.  There  is  no  information  on  the  objects 
that  lay  behind  this  point.  In  fact,  depth  maps  have  recently  been  proposed  as  a 
method  of  creating  shadow  volumes. 

The  depth  map  is  built  by  constructing  a  two-dimensional  grid  at  some 
virtual  location  between  the  threat  and  the  target.  A  line  is  traced  from  the 
threat’s  eye  position  through  the  center  of  each  cell  on  the  grid.  The  distance  to 
the  first  object  encountered  is  stored  as  the  value  for  the  cell.  If  the  trace  does 
not  encounter  any  objects,  then  some  null  value  is  stored. 

Building  the  depth  map  with  rear-facing  polygons  provides  the  same 
benefits  as  it  did  with  SVBSP  trees.  We  want  to  find  things  that  we  can  get 
behind,  not  inside.  Only  considering  rear-facing  polygons  in  the  area  of  interest 
can  eliminate  some  points  inside  solid  objects  from  consideration. 

Once  we  build  the  depth  map,  we  can  use  templates  of  our  agent  to 
determine  where  there  is  cover.  The  templates  tell  us  how  many  cells  our  agent 
covers  on  the  depth  map  for  a  certain  posture  at  a  certain  distance.  So  for 
instance,  we  may  have  one  template  that  tells  us  that  our  agent  appears  to  be 
one  cell  wide  and  two  cells  tall  at  120  meters  while  standing.  Another  template 
would  tell  us  that  our  agent  appears  to  be  three  cells  wide  and  five  cells  tall  at  a 
distance  of  30  meters  while  standing.  We  must  build  one  set  of  templates  for 
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each  posture  that  our  agent  is  capable  of  assuming  (i.e.  standing,  kneeling,  and 
prone). 

In  order  to  find  all  cover  locations  we  must  check  every  cell  in  our  depth 
map  against  the  templates  for  each  posture.  Starting  with  the  furthest  template, 
check  its  distance  against  the  distance  of  the  cell.  If  the  distance  stored  in  the 
cell  is  less  than  the  distance  for  the  template,  then  we  check  all  of  the  other  cells 
covered  by  the  template.  If  all  of  these  cells  are  also  closer  than  the  distance  to 
the  template,  then  we  have  cover  at  that  location  for  that  posture  and  distance. 
The  next  step  is  to  check  each  of  the  closer  templates  until  we  find  the  closest 
template  of  that  stance  that  allows  us  to  be  in  cover.  The  initial  locations  of  our 
cover  positions  can  be  computed  using  a  vector  to  the  bottom  center  of  each 
element  and  the  distance  stored  there.  (See  Figure  7) 


Templates  to  be  checked 


2nd  Check  =  Cover  3rd  Check  =  No  Cover 
Closest  cover  for  this  element  is  at  a  distance  of  250. 

Figure  7.  Checking  a  Sensor  Grid  Element  for  Cover 

After  we  have  determined  the  cover  positions  for  the  sensor  grid,  we  must 
determine  if  there  is  a  corresponding  covered  place  we  can  stand.  Due  to  the 
way  that  we  have  constructed  the  sensor  grid  so  far,  it  is  entirely  possible  that  the 
locations  we  have  stored  are  actually  floating  in  the  air  or  under  the  surface  of 
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the  terrain.  Since  we  have  stored  the  closest  possible  cover  position,  we  can 
trace  a  line  from  the  threat’s  eye  position,  through  the  bottom  of  the  sensor  grid 
element  until  it  hits  the  terrain.  If  a  standable  position  exists  along  this  line,  we 
move  our  initial  cover  locations  back  to  this  point.  (See  Figure  8) 


Figure  8.  Moving  Cover  Locations  to  Standable  Positions 

After  iterating  over  all  squares  in  the  depth  map  with  all  postures,  we  will 
have  a  list  of  points  that  are  in  cover,  and  on  a  standable  surface.  Each  position 
in  the  list  will  also  have  a  posture  associated  with  it.  From  this  point,  we  can 
determine  which  points  are  reachable  and  which  point  we  want  to  move  to. 

3.  Steps  in  the  Algorithm 

Our  algorithm  for  finding  cover  using  depth  mapping  has  the  following 

steps: 

•  Determine  the  location  of  the  threat. 

•  Build  the  depth  map  for  the  scene  from  the  threat’s  point  of  view. 

•  For  each  element  in  the  depth  map  find  the  closest  prone,  kneeling, 
and  standing  template  that  is  completely  covered. 

•  For  each  prone,  kneeling  and  standing  position  identified  so  far, 
move  the  point  away  from  the  threat  till  it  rests  on  standable  terrain. 
Discard  any  points  where  standable  terrain  does  not  exist. 

•  Test  the  remaining  points  and  discard  any  that  are  not  reachable. 

•  Choose  one  of  the  remaining  points  and  move  there. 

4.  Benefits 

One  benefit  of  the  Depth  Mapping  method  is  that  you  do  not  have  to 
perform  any  separate  checks  to  determine  if  you  will  fit  inside  the  area  of  cover. 
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Because  of  the  way  we  processed  the  depth  map  information  we  are  guaranteed 
to  fit  in  the  cover  at  that  point  or  some  other  point  further  away. 

Another  benefit  is  that  Depth  Mapping  also  gives  you  a  definite  location  to 
move  to.  Even  though  this  point  may  not  be  navigable,  we  know  that  we  can 
search  for  navigable  points  along  the  line  away  from  the  threat  and  still  remain  in 
cover. 

Depth  mapping  has  no  problems  with  objects  made  of  large  numbers  of 
polygons.  Since  only  one  check  is  made  in  each  area,  the  number  of  polygons  in 
the  scene  have  do  not  affect  the  functioning  of  the  algorithm. 

5.  Problems 

Depth  maps  are  approximations  of  the  surface  area  of  the  cover.  As  such 
they  give  you  very  little  information  about  anything  behind  the  surface.  There 
may  be  many  objects  that  are  stacked  close  enough  together  that  you  cannot 
move  there,  but  the  Depth  Map  does  not  provide  you  with  any  additional 
information  about  it.  The  hardest  part  of  this  algorithm  will  be  determining  if  the 
area  behind  the  front  of  edge  of  the  depth  map  provides  enough  room  for  you  to 
navigate. 

Depth  maps  are  less  computationally  expensive  than  the  shadow  volume 
method,  but  still  very  expensive.  The  actual  expense  for  performing  the 
algorithm  will  depend  on  the  size  of  the  grid  and  the  efficiency  of  the  line  of  sight 
algorithm.  As  the  number  of  points  in  the  horizontal  and  vertical  planes 
increases  linearly,  the  number  of  points  that  must  be  tested  and  calculated  over 
the  whole  grid  increase  exponentially.  Increasing  the  number  of  points  to  be 
tested  also  increases  the  number  of  templates  that  must  be  stored  for  testing. 

F.  SENSOR  GRID 

1.  Definition 

A  sensor  grid  is  a  group  of  objects  that  are  used  to  gather  information 
about  the  surrounding  area.  The  types  of  information  that  the  sensors  gather 
depends  on  the  type  of  sensor  and  the  information  available  from  the 
environment.  The  sensors  are  arranged  in  some  pattern,  or  grid,  that  gives  them 
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systematic  coverage  of  the  area  of  interest.  Often  this  pattern  is  some  sort  of 
even  spacing,  but  it  can  also  be  modified  so  that  there  is  a  higher  density  of 
coverage  in  areas  where  more  detailed  information  is  necessary. 

2.  Concept  Applied  to  Finding  Cover 

A  sensor  grid  can  be  used  to  sample  the  area  around  an  agent  to  find 
cover  in  its  environment.  When  the  agent  needs  to  find  cover,  it  deploys  the  grid 
and  uses  the  sensors  to  gather  information  on  cover  locations.  It  can  then  use 
this  information  to  choose  a  cover  location  and  then  move  to  that  sensor’s 
location. 

The  sensors  used  in  this  method  can  be  very  simple.  At  the  most  basic 
level  all  that  the  sensor  needs  to  be  is  a  location  in  space.  We  can  determine  if  a 
sensor  is  in  cover  if  we  do  a  line  of  sight  check  between  the  threat  and  the 
location  of  the  sensor.  If  the  line  of  sight  check  is  blocked,  then  we  can  assume 
that  the  location  offers  cover.  Additional  information  that  might  be  useful  to  store 
in  the  sensor  would  be  if  the  location  is  over  standable  terrain  and  the  posture 
that  the  agent  will  need  to  take  to  benefit  from  the  cover. 

The  deployment  and  arrangement  of  the  sensor  grid  can  have  a  large 
effect  on  the  number  of  sensors  required  to  cover  an  area  and  the  quality  of  the 
results  returned  by  the  algorithm.  While  it  is  perfectly  possible  to  arrange  the 
sensors  in  a  grid  that  uniformly  covers  an  area  around  the  agent  in  the  x,  y,  and  z 
directions,  it  is  not  necessary.  Under  most  conditions,  the  vast  majority  of  the 
movement  of  the  agent  will  be  in  horizontal  directions.  Ground  is  generally  flat 
and  we  tend  to  think  about  ground  movement  in  horizontal  planes.  Our  elevation 
is  a  matter  of  gravity  holding  us  to  the  current  ground  level.  We  can  take 
advantage  of  this  in  the  development  of  our  sensor  grid  pattern. 

One  horizontal  layer  of  sensors,  clamped  to  ground  level,  can  reduce  the 
number  of  required  sensors  while  still  finding  cover  around  the  agent.  If  the 
sensor  grid  extends  both  in  the  horizontal  and  vertical  directions  with  no  regard  to 
ground  level,  a  lot  of  them  will  provide  meaningless  information.  Sensors  that 
are  too  far  above  ground  level  will  be  testing  points  up  in  the  air  that  we  cannot 
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reach.  Sensors  that  are  below  ground  level  will  also  be  in  unreachable  positions. 
(See  Figure  9  below)  Eliminating  these  sensors  greatly  reduces  the  number  of 
checks  that  the  algorithm  must  perform  when  they  are  not  likely  to  produce  useful 
results  anyway. 


In  the  air 


Underground 


Figure  9.  Problems  with  a  Flat  Horizontal  Layer  of  Sensors 

We  must  carefully  consider  the  arrangement  of  the  sensors  in  the 
horizontal  plane  of  the  sensor  grid  to  ensure  that  it  produces  good  results.  The 
first  thing  that  we  must  determine  is  how  large  of  an  area  we  want  the  sensor  grid 
to  cover.  It  should  be  large  enough  that  all  cover  locations  within  a  reasonable 
distance  are  considered.  The  second  item  we  must  consider  is  the  density  of  the 
sensor  locations;  that  is  how  close  together  we  want  them.  If  the  sensors  are  too 
far  apart,  they  will  not  detect  cover  opportunities.  If  the  sensors  are  too  close 
together,  the  number  of  sensors  can  grow  so  large  that  the  algorithm  is  too  slow 
for  real-time  operation.  There  must  be  a  balance  between  resolution  and  speed. 
The  last  item  that  we  must  consider  is  whether  the  sensors  have  an  even  spread. 
Spreading  the  sensors  in  an  uneven  fashion  will  leave  gaps  in  coverage  and 
some  valid  cover  locations  will  not  be  considered. 

When  testing  a  sensor  location  for  cover  there  are  four  cases  that  we  must 
consider:  no  cover,  cover  while  prone,  cover  while  kneeling,  cover  while 
standing.  This  assumes  that  all  three  of  these  postures  are  available  to  the 
agent.  The  easiest  way  to  determine  which  case  applies  to  the  sensor’s  location 
is  to  start  from  the  ground  up.  Since  almost  all  objects  that  provide  cover  are  on 
the  ground  (or  are  the  ground  itself)  it  makes  sense  to  start  there.  There  are  also 
some  situations  where  a  person’s  leg  may  be  exposed,  but  their  upper  bodies 
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are  in  cover.  Checking  from  the  ground  up  allows  us  to  quickly  label  places  with 
no  cover  and  stop  checking.  If  that  location  has  some  cover,  then  we  can  do  a 
more  detailed  examination  of  the  location  to  determine  which  posture  is  the 
highest  we  can  maintain  and  still  be  in  cover. 

3.  Steps  in  the  Algorithm 

Our  algorithm  for  finding  cover  with  a  sensor  grid  has  the  following  steps: 

•  Determine  the  location  of  the  threat. 

•  Create  the  sensor  grid  in  the  predetermined  pattern. 

•  Clamp  the  sensors  to  ground  level. 

•  Determine  which  sensors  are  on  standable  terrain. 

•  Test  line  of  sight  to  the  sensors  and  classify  them. 

•  Of  the  sensors  that  are  in  cover  and  on  standable  terrain, 
determine  which  ones  are  reachable. 

•  Choose  a  sensor  that  is  in  cover,  on  standable  terrain,  and 
reachable  as  your  destination. 

•  Move  to  that  sensor’s  location. 

4.  Benefits 

Of  all  the  algorithms  presented  so  far,  the  sensor  grid  is  the  most 
computationally  efficient.  As  the  polygon  count  of  the  scene  increases,  the 
algorithm  the  only  thing  that  affects  the  speed  of  the  algorithm  is  the  efficiency  of 
the  line  of  sight  algorithms  that  it  depends  on.  It  handles  objects  made  of  single 
polygons  or  millions  of  polygons  just  as  efficiently.  The  biggest  impact  on  the 
speed  of  the  algorithm  is  the  number  of  sensors  used.  As  the  number  of  sensors 
increases,  the  number  of  line  of  sight  checks  for  finding  cover  only  increases 
linearly. 

The  Sensor  Grid  algorithm  gives  you  half  of  a  navigation  solution  before 
you  even  begin  to  calculate  which  points  are  reachable.  Since  algorithm  already 
requires  us  to  clamp  the  sensors  ground  level  in  a  regular  pattern,  we  can  use 
them  as  temporary  waypoints.  This  allows  us  to  efficiently  navigate  around 
objects  into  cover  locations. 

The  Sensor  Grid  considers  all  of  the  area  around  the  agent  equally.  The 
other  two  algorithms  we  have  considered  create  a  “cover  surface”  where 
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anything  that  is  behind  it  is  in  cover.  This  algorithm  can  deal  with  objects  placed 
one  behind  the  other  in  arbitrarily  complicated  scenes. 

5.  Problems 

The  Sensor  Grid  method  conducts  a  low  detail  sampling  of  the  area.  As 
such  it  may  miss  some  cover  opportunities.  Points  that  are  in  between  two  of  the 
sensor  may  provide  good  cover,  but  will  never  be  considered. 

The  Sensor  Grid  method  is  prone  to  false  reporting  in  situations  with  large 
numbers  of  small  objects.  This  is  because  the  line  of  sight  checks  are  conducted 
from  point  to  point,  not  point  to  area.  It  may  be  the  case  that  an  object  is  large 
enough  and  in  the  right  position  to  block  the  line  of  sight  check  while  other  parts 
of  the  target  are  clearly  visible. 

The  Sensor  Grid  method  reports  the  insides  of  objects  as  valid  cover 
locations.  Since  the  cover  determination  is  based  purely  on  line  of  sight,  the 
insides  of  solid  objects  will  be  reported  as  providing  cover.  It  is  not  until  we 
attempt  to  navigate  to  these  locations  that  we  find  that  they  cannot  be  reached. 
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V.  IMPLEMENTATION  OF  THE  SENSOR  GRID  MODEL 


A.  INTRODUCTION 

This  chapter  describes  our  implementation  of  the  sensor  grid  model  inside 
of  the  computer  game  America’s  Army:  Operations  (AAO).  AAO  is  based  on  the 
Unreal  Engine  so  the  first  section  gives  some  background  on  it  and  what  it  has  to 
offer  as  a  three-dimensional  virtual  environment.  The  second  section  describes 
the  Army  Game  Project  and  some  of  the  modifications  that  they  have  made  to 
the  Unreal  Engine.  The  last  section  details  how  we  built  an  agent  in  AAO  that 
uses  the  sensor  grid  method  to  find  cover. 

B.  THE  UNREAL  ENGINE 

Tim  Sweeney,  the  founder  of  Epic  Games,  developed  the  Unreal  Engine. 
He  began  research  in  1994  and  published  the  engine  in  1998  [21].  His  design 
goals  were  to  allow  developers  to  create  true  three-dimensional  environments 
and  to  enable  programmers  to  control  and  customize  all  aspects  of  the 
environment  and  characters.  The  game  engine  has  been  constantly  improved 
over  the  last  five  years  and  is  one  of  the  best  of  its  kind.  It  is  not  only  featured  in 
the  Unreal  series  of  games,  but  has  also  been  licensed  by  many  other 
companies  to  use  in  their  games. 

Programming  in  the  Unreal  Engine  is  written  in  accomplished  through  the 
use  of  UnrealScript  and  C++.  It  supports  full  four-way  function  calling  between 
C++  and  UnrealScript,  so  developers  can  freely  mix  code  between  the  two. 
While  Unrealscript  runs  many  times  slower  than  C++  code  in  the  game,  it  is  more 
simple  to  use  in  some  cases.  UnrealScript  looks  like  a  cross  between  Java  and 
C++  with  some  additional  added  features.  Two  important  capabilities  of 
UnrealScript  for  agent  programming  are  state-based  execution  and  time-based 
execution.  Agents  behaviors  are  controlled  by  their  current  state  and  changes  in 
state.  Time-based  execution  allows  the  modeling  of  actions  that  take  a  certain 
amount  of  real-life  time  to  complete,  without  constantly  checking  to  see  if  it  is 
complete. 
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The  Unreal  Engine  is  an  idea  environment  for  exploring  agent-based 
research.  It  provides  a  highly  detailed  three-dimensional  environment  with 
realistic  physics.  It  has  built-in  support  for  artificial  intelligence  programming. 

C.  THE  ARMY  GAME  PROJECT 

The  Army  Game  Project  is  an  attempt  by  the  U.S.  Army  to  allow  civilians 
to  learn  about  the  Army  through  a  computer  game  called  “America’s  Army: 
Operations”  [1].  The  Assistant  Secretary  of  the  Army  for  Manpower  and  Reserve 
Affairs  selected  the  Modeling  Virtual  Environments  and  Simulation  (MOVES) 
Institute  at  the  Naval  Post  Graduate  School  to  develop  the  game.  Development 
began  in  January  2000  and  it  was  first  published  in  July  2002.  Since  then  over 
1.67  million  people  have  downloaded  the  software  for  free.  Users  have  played 
over  130  million  missions  logging  a  staggering  13  million  hours  of  game  play. 

America’s  Army:  Operations  (AAO)  has  many  features  that  made  it  our 
first  choice  for  this  research.  AAO  is  based  on  the  Unreal  Engine,  which  is  easy 
to  learn  and  provides  a  rich,  detailed  three-dimensional  environment.  Since  the 
MOVES  program  developed  the  game,  we  had  easy  access  to  the  code  and 
many  people  with  significant  experience  with  Unreal  programming  experience. 

One  of  the  most  significant  reasons  for  using  AA:0  is  that  the  computer- 
controlled  agents  can  go  prone.  Many  of  the  games  published  today  do  not  have 
this  feature.  In  fact,  the  base  Unreal  Engine  itself  does  not  support  the  ability  for 
people  to  go  prone.  We  feel  that  the  ability  to  go  prone  is  an  essential  part  of 
making  realistic  use  of  cover,  so  it  was  essential  that  our  development 
environment  supported  this  ability. 

We  used  version  1 .6  of  America’s  Army:  Operations  for  all  of  our 
research. 

D.  COVERBOT 

1.  General 

CoverBot  is  our  implementation  of  the  sensor  grid  method  of  finding  cover 
inside  of  America’s  Army:  Operations.  There  are  two  versions  of  CoverBot:  a 
step-by-step  version  called  CoverBot  and  a  full-speed  version  called 
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CoverBotTwo.  CoverBot  stops  after  each  major  step  of  the  algorithm  to  allow 
verification  of  its  results.  CoverBotTwo  executes  without  any  stops  to  allow  us  to 
see  it  run  at  full  speed. 

2.  Flow  of  Execution 

Both  of  the  CoverBots  have  essentially  the  same  flow  of  execution.  The 
only  real  difference  is  that  the  sensor  grid  for  the  step-by-step  version  is 
deployed  immediately  while  the  agent  is  in  the  waiting  state.  This  makes  it  easier 
to  test  the  Bot  because  we  can  see  where  the  sensors  are  that  it  will  be  using. 

Both  of  the  CoverBots  start  in  a  standing  position  and  go  into  a  waiting 
state.  We  use  the  “takeDamage”  message  from  the  game  engine  to  trigger  the 
agents  to  advance  through  each  phase  of  the  algorithm.  The  game  engine 
sends  this  message  to  the  agent  each  time  we  shoot  it  so  we  can  use  our  rifle  to 
control  the  flow  of  the  algorithm  inside  the  simulation. 

The  next  step  is  for  the  agent  to  create  the  sensor  grid.  The  agent 
determines  the  placement  of  each  sensor  based  on  a  pattern  centered  on  the  its 
current  location.  When  the  initial  position  of  each  sensor  is  determined,  the 
agent  attempts  to  clamp  the  sensor  to  the  terrain  at  that  position.  If  it  is 
successful,  it  also  checks  if  the  terrain  at  that  location  is  standable.  If  there  is  a 
standable  surface  at  that  location,  the  agent  creates  a  sensor  there. 

After  the  agent  places  all  of  the  sensors  in  the  pattern,  it  determines  which 
of  them  are  in  cover.  For  each  sensor,  the  agent  checks  line  of  sight  to  three 
different  positions.  The  agent  moves  the  sensor  from  ground  level  to  the  prone 
height  of  the  agent,  to  the  kneeling  height,  to  the  standing  height.  At  each  height 
it  checks  the  line  of  sight  between  the  enemy  and  the  sensor’s  location.  The 
agent  then  picks  one  of  four  cover  categories  for  the  sensor’s  location:  no  cover, 
cover  while  prone,  cover  while  kneeling,  or  cover  while  standing. 

After  the  agent  has  categorized  the  cover  at  all  of  the  sensor  locations,  it 
tries  to  determine  the  shortest  path  to  any  of  the  points  that  have  cover.  For 
each  sensor  in  cover,  the  agent  checks  to  see  if  there  is  a  straight-line  path  to  the 
sensor’s  location.  If  no  direct  path  exists,  it  checks  to  see  if  it  can  reach  the 
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cover  location  by  traveling  through  any  of  the  other  sensor  locations  first. 
Essentially,  it  is  using  the  other  sensors  as  waypoints  for  a  two-part  path  to  the 
cover  location. 

The  agent  selects  a  movement  destination,  by  finding  the  shortest  path 
into  a  sensor  position  that  provides  cover.  If  a  valid  path  is  found,  then  agent 
moves  to  that  position  and  then  changes  its  posture  based  on  how  the  cover  was 
classified  for  that  location.  The  agent  always  remains  at  the  tallest  posture  that  it 
can  assume  in  that  location  and  still  be  in  cover. 

Once  the  agent  reaches  cover,  we  can  reset  it  by  shooting  it  again.  The 
agent  will  stand  up  and  prepare  itself  to  deploy  the  sensor  grid  again. 

3.  Solutions  to  Problems 

The  following  paragraphs  provide  additional  details  on  how  we 
implemented  various  parts  of  the  algorithm. 

a.  Determining  the  Location  of  the  Enemy 

We  give  CoverBot  the  exact  location  of  the  enemy.  The 
“takeDamage”  message  that  is  used  to  control  the  flow  of  the  algorithm  also 
passes  the  agent  a  reference  to  us  (as  its  enemy).  From  this  it  can  determine 
where  our  eye’s  are  and  uses  this  location  for  determining  line  of  sight  to  the 
sensors.  The  agent  assumes  that  we  stay  in  the  position  where  we  initially  shot  it 
from  while  it  was  in  the  waiting  state.  This  allows  us  to  move  around  to  better 
viewpoints  during  execution. 

b.  Building  the  Sensor  Grid 

We  found  that  offset  rings  of  sensors  provide  excellent  coverage  of 
the  area  searched  for  cover.  A  traditional  grid  formation  would  place  the  sensors 
equidistant  from  each  other  over  a  square  area.  (See  Figure  10,  left  side) 
However  if  we  place  the  sensors  in  equidistant  rings  around  the  agent  with  each 
ring  containing  the  same  number  of  sensors  we  get  a  variable  density  coverage 
of  the  area.  The  density  of  sensor  points  is  highest  close  to  the  agent  and  lowers 
further  away  from  it.  (See  Figure  10,  center)  However,  this  variable  density  is 
actually  productive  to  the  algorithm.  It  allows  the  agent  to  make  a  more  detailed 

check  nearby  for  cover  while  still  considering  points  that  are  further  away.  This 
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seems  to  parallel  parts  of  the  human  cover-finding  process.  We  give  more 
consideration  to  nearby  locations  than  those  that  are  further  away  because  we 
can  reach  the  nearby  locations  faster.  Finally  looking  at  the  rings  of  sensor 
locations,  we  see  that  it  does  not  give  us  very  even  coverage  of  the  area.  Large 
gaps  in  coverage  have  developed  between  rows  of  sensors  as  you  travel 
outward  from  the  center  of  the  rings.  By  simply  offsetting  the  rotation  of  every 
other  ring  by  half  the  angle  between  adjacent  sensors  of  the  same  ring,  we  can 
even  out  our  coverage  and  still  maintain  a  pattern  that  is  denser  on  the  inside 
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Figure  10.  Sensor  Grid  Patterns 


c.  Clamping  the  Sensor  Grid  to  Ground  Level 

We  developed  the  following  method  for  clamping  our  sensors  to 
ground  level.  First,  the  sensors  were  deployed  in  a  horizontal  plane  from  the  foot 
level  of  the  agent.  A  trace  was  done  directly  down  from  each  sensor  to 
determine  if  the  surface  of  the  terrain  was  below  the  horizontal  plane.  If  this 
check  failed  to  produce  a  surface,  a  second  check  was  performed  from  above 
ground  level  down  to  the  horizontal  plane  to  find  a  surface.  If  no  surface  was 
detected  by  either  check  then  a  sensor  was  not  created.  (See  Figure  1 1  below) 
The  reason  that  we  check  was  split  into  two  parts  is  that  if  you  only  do  one  check 
from  top  to  bottom,  there  is  a  tendency  for  the  points  to  be  clamped  to  the  tops  of 
buildings  and  other  objects.  Checking  from  ground  level  down  first  also  gives  the 
agent  a  tendency  to  go  downhill  which  is  common  when  taking  cover  because  it 
is  easier  to  move  downhill. 
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Figure  1 1 .  Clamping  Sensors  to  Ground  Level 

Lines  that  extend  upwards  and  downwards  from  the  agent  at  45- 
degree  angles  limit  the  length  of  the  two  traces.  This  keeps  the  sensors  from 
being  placed  at  a  distance  that  was  too  far  up  or  down  for  the  agent  to  be  able  to 
reasonably  navigate  to.  We  do  not  want  our  agent  jumping  off  cliffs  to  take  cover 
or  trying  to  climb  up  areas  that  are  too  steep  to  climb.  However,  the  agent 
should  be  able  to  make  reasonable  small  jumps  down,  so  we  modified  the  lower 
boundary  line  to  allow  it  to  jump  down  up  to  its  own  height.  (See  Figure  12 
below) 


Figure  12.  Adjusting  the  Lower  Boundary  to  Allow  Small  Drops 
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While  clamping  the  sensors  to  ground  level,  we  should  also 
determine  if  the  surface  is  standable  or  not.  We  are  already  tracing  a  line  to  the 
surface  while  clamping  so  the  information  about  whether  or  not  the  surface  is 
standable  should  be  readily  available.  If  the  surface  is  not  standable,  then  we 
can  remove  the  sensor  from  consideration  as  a  cover  location  and  save  some 
computation  cycles. 

d.  Determining  if  a  Point  is  Standable 

In  order  to  determine  if  a  point  was  standable,  we  checked  to  see  if 
it  had  a  slope  of  less  than  45  degrees.  The  trace  function  that  we  used  in 
clamping  the  points  to  ground  level  returns  the  surface  normal  of  the  first  polygon 
it  intersects.  The  surface  normal  has  a  length  of  one.  At  a  slope  of  0  degrees 
the  z  component  of  the  surface  normal  is  equal  to  one.  At  a  slope  of  45  degrees 
the  z  component  of  the  surface  normal  is  equal  to  the  square  root  of  two.  So  if 
the  Z  component  of  the  surface  normal  is  greater  than  the  square  root  of  two,  we 
consider  the  surface  to  be  standable.  (See  Figure  13  below) 


Figure  13.  Determining  Standability 

e.  Finding  Cover 

We  check  for  cover  by  moving  the  sensor  to  the  appropriate  height 
above  ground  level  and  checking  for  line  of  sight.  Start  with  the  prone  height  for 
the  agent  and  check  if  the  sensor  has  line  of  sight.  If  line  of  sight  exists,  then 
there  is  no  cover.  If  line  of  sight  does  not  exist,  the  continue  checking  the  next 
highest  stance,  until  the  line  of  sight  check  is  clear  or  there  is  no  line  of  sight  to 
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the  sensor  at  standing  height.  If  the  line  of  sight  was  clear  to  any  sensor  height, 
then  the  next  lowest  stance  is  the  tallest  stance  that  the  agent  can  take  at  that 
location  and  still  have  cover.  If  line  of  sight  is  blocked  even  in  the  standing 
position,  then  the  agent  can  take  any  posture  at  that  location  and  still  be  in  cover. 
Figure  14  below  summarizes  this  procedure  in  pseudo  code. 


If  (LOS  to  PRONE) 

then  NO_COVER; 

Else  if  (LOS  to  CROUCHING) 
then  PRONE_COVER; 

Else  if  (LOS  to  STANDING) 

then  CROUCH  COVER; 
Else  STANDING_COVER; 

Figure  14.  Determining  Type  of  Cover  with  Sensors 

f.  Point-to-Point  False  Cover  Results 

Since  we  are  checking  line  of  sight  from  one  point  to  another  point, 
small  objects  and  the  edges  of  objects  can  appear  to  provide  cover  when  they  do 
not.  This  is  because  the  point  to  point  check  does  not  take  into  account  the  area 
that  the  agent  will  occupy  when  it  moves  to  that  location.  We  avoided  this 
problem  by  doing  additional  checks  for  locations  that  initially  reported  cover.  We 
performed  two  more  checks  to  points  that  we  moved  to  the  left  and  the  right  of 
the  sensor  by  the  collision  radius  of  the  agent.  Since  the  collision  cylinder  for  the 
agent  is  slightly  larger  than  the  actual  polygon  model  for  the  object,  this  provides 
us  with  a  conservative  estimate  of  positions  that  will  provide  cover. 


Threat 


Agent 


STANDING 


A 


CROUCHING 
PRONE 
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Threat 


Agent 


Threat 


Agent 


Line  of  sight  only 
appears  to  be  blocked. 


Checking  the  edges  shows 
this  to  be  a  bad  spot. 


Figure  15.  Checking  for  False  Cover  Results 


g.  Determining  if  a  Point  is  Reachable 

We  considered  a  point  reachable  if  a  direct  path  or  a  path  that  went 
through  one  other  sensor  could  reach  it.  We  used  two  functions  to  determine  if  a 
point  was  reachable  from  another  point.  The  first  function,  “pointReachable”,  is 
native  to  the  Unreal  Engine.  It  returns  a  Boolean  value  that  tells  you  if  the  agent 
can  move  from  its  current  location  directly  to  a  specified  location  in  a  straight  line. 
However,  this  function  cannot  does  not  work  if  the  starting  point  is  not  the  agent’s 
current  location.  To  determine  if  the  destination  point  could  be  reached  from 
another  sensor’s  location  we  used  a  volumetric  line  of  sight  check.  This  function 
determines  if  an  upright  cylinder  that  moves  from  one  point  to  another  intersects 
any  objects. 


Point  Directly  Reachable  Point  Reachable  Through 

Another  Sensor 


Figure  16.  Checking  if  a  Point  is  Reachable 
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h.  Deciding  Where  to  Go 

Instead  of  implementing  complicated  decision  logic  about  where  the 
agent  should  take  cover,  we  decided  to  go  with  a  simple,  effect  solution.  Our 
agent  goes  to  the  closest  point  in  cover  that  it  can  reach. 

4.  Running  the  Demonstration 

a.  Loading  the  Environment 

On  the  CD  you  will  find  a  directory  named  “/FireTeam”.  Copy  this 
directory  directly  to  your  hard  drive.  Once  this  is  complete  change  to  the 
“/system”  directory  and  run  the  file  called  “ArmyOps.exe”.  This  starts  the  game. 


Once  the  menu  screen  is  displayed,  hit  the  key  to  open  a 
command  prompt.  To  load  the  demonstration  level,  type  “open  test”  at  the 
command  prompt.  Once  the  level  has  loaded  you  will  need  to  type  “class  r”  to 
give  yourself  a  rifle  and  unlock  your  movement  controls. 

b.  Heads-Up  Display 


CoverBot 


FireFly 


ass  Dire 


Jpul 


Aim  Poi 


Your  Posture 


Rounds  Remaining 


Magazines  Remaining 


Figure  17.  Heads-Up  Display  Features 
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c.  Controls 


Use  the  following  commands  to  navigate  through  and  interact  with 
the  environment: 


ACTION 

KEY 

Move  Forward 

W 

Move  Back 

s 

Move  Left 

A 

Move  Right 

D 

Run 

Ctrl 

Jump 

Spacebar 

Look  Left  /  Right  /  Up  /  Down 

Move  Mouse 

Go  From  Standing  or  Prone  to  Kneeling 

C 

Go  From  Kneeling  to  Standing 

C 

Go  From  Standing  or  Kneeling  to  Prone 

X 

Go  From  Prone  to  Standing 

X 

Bring  up  Weapon  Sights 

Z 

Fire  Weapon 

Left  Mouse  Button 

Reload  Weapon 

R 

Fix  Jam 

F 

Open  /  Close  the  Command  Consol 

~ 

Toggle  Between  Main  Menu  and  Demonstration 

ESC 

Table  1 .  Keyboard  and  Mouse  Commands. 

d.  Consol  Commands 

Use  the  following  commands  at  the  command  prompt  in  the  consol: 


ACTION 

COMMAND 

Unlock  Movement 

playerlock  0 

Change  Player  Class  to  Rifleman 

class  r 

Give  the  Player  Unlimited  Ammo 

mpcheat  params  ammo  true 

End  the  Demonstration 

quit 

Load  the  Demonstration 

load  test 

Render  Scene  in  Normal  Mode 

rmode  5 

Render  scene  with  polygons  only 

rmode  1 

Table  2.  Consol  Commands. 
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e.  Map  of  the  Demonstration 

The  figure  below  shows  a  map  of  the  demonstration  area.  This  is 
not  a  map  of  the  entire  level.  The  Coverbots  have  been  placed  in  a  variety  of 
locations  so  that  its  abilities  can  be  tested.  The  compass  in  the  lower  left  corner 
of  the  map  shows  where  North  is  on  the  map. 


P  =  Player  starting  position  3  =  CoverBot 

1  =  CoverBot  4  =  CoverBot 

2  =  CoverBot  5  =  CoverBot2 


Figure  18.  Map  of  the  Demonstration  Level 

f.  CoverBot 

CoverBot  is  a  step-by-step  implementation  of  the  sensor  grid 
algorithm.  It  starts  in  a  waiting  state  with  its  sensor  grid  already  deployed  and 
clamped  to  the  ground.  The  sensors  appear  as  glowing  balls  of  light  that  we  call 
FireFlys.  The  trigger  for  making  CoverBot  execute  the  next  step  of  the  algorithm 
is  to  shoot  him  with  your  rifle. 

The  first  time  that  you  shoot  CoverBot,  he  uses  the  sensor  grid  to 

find  cover  and  plans  a  path  to  the  shortest  point  in  cover.  He  uses  your  location 
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from  this  first  shot  throughout  the  rest  of  the  process  until  he  resets.  This  allows 
you  to  move  around  him  and  see  what  is  going  on. 


When  CoverBot  checks  the  sensor  grid  for  line  of  sight  the  FireFlys, 
he  makes  the  ones  that  are  in  your  line  of  sight  invisible.  The  FireFlys  that  are  in 
cover  are  moved  to  a  height  that  indicates  whether  that  position  provides  cover 
prone,  kneeling,  or  standing.  The  Firefly  that  is  at  the  location  where  the 
CoverBot  has  decided  to  take  cover  is  made  six  times  larger  than  the  others.  If 
the  CoverBot  needs  to  go  through  one  of  the  other  FireFlys  to  get  to  that  location 
it  is  made  three  times  larger  than  the  others  and  is  shown  regardless  of  whether 
or  not  it  is  in  cover. 

The  second  time  that  you  shoot  the  CoverBot,  it  moves  to  the  cover 
location  that  it  decided  on  in  the  last  step.  It  then  assumes  the  posture 
necessary  to  have  cover. 

Shooting  the  CoverBot  a  third  time  resets  it.  It  stands  back  up  in  its 
current  position  and  redeploys  its  sensor  grid. 

g.  CoverBotTwo 

CoverBotTwo  is  a  full  speed  version  of  CoverBot.  Its  sensor  grid  is  not 
initially  deployed  and  it  does  not  use  any  FireFlys  to  show  the  location  of  its 
sensors.  The  first  time  you  shoot  CoverBotTwo,  it  immediately  moves  into  cover 
and  assumes  the  required  posture.  Shooting  it  a  second  time  resets  it. 
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Figure  19.  CoverBot  with  Sensors  Clamped  to  Ground  Level 


Figure  20.  Sensors  Showing  Location  Selected  and  Final  Posture 
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Figure  21 .  CoverBot  after  Moving  into  Cover 
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VI.  CODE 


A.  INTRODUCTION 

This  chapter  includes  all  of  the  code  that  we  used  in  our  implementation  of 
the  sensor  grid  method  of  finding  cover  in  the  America’s  Army:  Operation.  All  of 
the  code  is  written  in  UnrealScript.  Firefly. uc 

B.  FIREFLY.UC 


/*  ================================================================ 

*  Filename:  FireFly.uc 

*  Date:  19  SEP  2003 

*  Author:  MAJ  David  J.  Morgan,  U.S.  Army 

k  ———————————————————————————————————————————————————————————————— 

*  This  displays  a  glowing  ball  of  light  in  the  level  that  does  not 

*  block  anything. 

*  ================================================================ 

*/ 

class  FireFly  extends  Light 
placeable; 


def aultproperties 

{ 

bstatic=False 

bNoDelete=False 

bMovable=True 

bHidden=False 

bBlockBulletTraces=False 

bBlockNonZeroExtentTraces=False 

bBlockZeroExtentTraces=False 

Texture=Texture ' T2-FX . Corona . fx2  cor  05' 

Style=STY  Translucent 

} 
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c. 


NPC  COVERBOT.UC 


/*  =================================================================== 

*  Filename:  NPC_CoverBot . uc 

*  Date:  19  SEP  2003 

*  Author:  MAJ  David  J.  Morgan,  U.S.  Army 

*  =================================================================== 

*  This  class  tells  the  engine  which  skins  and  what  controller  to  use 

*  for  the  hot. 

*  =================================================================== 

*/ 

class  NPC  CoverBot  extends  AGP_Character 
placeable; 


function  TakeDamage ( int  Damage,  Pawn  InstigatedBy,  Vector  HitLocation, 

Vector  Momentum,  class<DamageType>  DamageType, 

optional  Bonelnfo  Bone, 

optional  Controller  KillerController ) 

{ 


} 


Controller . TakeDamage (Damage,  InstigatedBy,  HitLocation,  Momentum, 

DamageType,  Bone,  KillerController) ; 


def aultproperties 

{ 


Skins [ 0 ] =Texture ' T-Characters . Soldier . Soldier  PANTS  Tiger  Opfor' 
Skins [ 1 ] =Texture ' T-Characters . Soldier . Soldier  SHIRT  Tiger  Opfor' 
Skins [2 ] =Texture ' T-Characters . Soldier . Soldier  HAND  Blk  Gloves  Ip' 
Skins [ 3 ] =Texture ' T-Characters . Soldier . Soldier  FACE  Opfor  008' 

Mesh=Mesh ' Soldier  3PMesh' 

bStaticSkinsAndMeshes  =  true; 

Control lerClass=class ' AGP . CoverBotCont roller ' 

} 
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D. 


COVERBOTCONTROLLER.UC 


/*  ==================================================================== 

*  Filename:  CoverBot2controller . uc 

*  Date:  19  SEP  2003 

*  Author:  MAJ  David  J.  Morgan,  U.S.  Army 

*  ==================================================================== 

*  Base  AI  for  CoverBots  with  step-by-step  execution.  The  bot 
starts 

*  in  a  waiting  state.  Glowing  balls  called  "FireFlys"  are  used  to 

*  indicate  the  position  of  the  sensors  in  the  sensor  grid.  The 

*  trigger  for  the  bot  to  change  states  is  the  takeDamage  function. 

*  The  first  time  the  bot  takes  damage  it  searches  the  sensor  grid  for 

*  cover  locations  and  path  into  cover.  The  sensors  that  are  not  in 

*  cover  are  made  invisible.  The  sensors  that  are  in  cover  are  moved 

*  to  the  height  of  the  highest  posture  that  the  bot  can  assume  at 

*  that  location  and  still  be  in  cover.  The  FireFly  for  the  sensor 

*  that  the  bot  has  chosen  as  its  destination  is  made  very  large  and 

*  if  an  intermediate  sensor  is  needed  to  get  there,  it  is  made  medium 

*  sized.  When  the  bot  takes  damage  a  second  time  it  moves  to  the 

*  cover  location  that  it  chose  initially  and  assumes  the  correct 

*  posture.  When  it  takes  damage  a  third  time  it  resets  itself  into 

*  the  waiting  state. 

*  ==================================================================== 

*/ 


class  CoverBotController  extends  AgentController ; 


/************************/ 
/*  VARIABLES  */ 

/************************/ 


var  Color 
var  int 

FireFly 
int 
int 
int 
float 
var  Actor 
var  bool 
var  int 


var 

var 

var 

var 

var 


red,  green,  blue,  purple; 
displayTime; 
f ireFly [ 51 ] ; 
num  rings; 
num  points; 
num  fireFlys; 


//  Colors  for  messages 
//  Display  time  messages 
//  need  (num_rings  *  num_points)  +  1 
//  number  of  rings  of  FireFlys 
/ /  number  of  FireFlys  per  ring 
/ /  number  of  FireFlys  actually  created 
distance  between  rings; 

midpoint,  endpoint;  //  path  to  the  point  in  cover 

foundCover,  foundPath; 

middle,  end;  //  used  for  navigation 


var  enum  CoverType 

{ 

Standing, 

Crouching, 

Prone, 

NoCover 

}  cover [51];  //  need  (num  rings  *  num  points)  +  1  of  these 

//  there  is  a  1-to-l  correspondence  between  the  index  of  the  cover  and 

//  the  sensor 
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/************************ / 
/*  PREGAME PLAY  */ 

/************************  I 

function  PreBeginPlay ( ) 

{ 

Super . PreBeginPlay ( ) ; 

} 

function  BeginPlayO 

{ 

Super . BeginPlay ( ) ; 

} 

function  PostBeginPlay ( ) 

{ 

Super . PostBeginPlay ( ) ; 

} 


/********************************************************************* 

*  This  method  does  some  initialization  of  some  variables  when  the 

*  CoverBot  is  created. 

•k-k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'kj 

function  Possess (Pawn  aPawn) 

{ 

Super .Possess (aPawn) ; 


//  set  colors  for  printing  messages  to  the  console 


red .  R 

255; 

red.G  = 

0; 

red .  B 

=  0; 

red.  A 

=  255; 

green. R  = 

0; 

green. G  = 

255; 

green  .  B 

=  0; 

green .A 

=  255; 

blue.R  = 

0; 

blue.G  = 

0; 

blue . B 

=  255; 

blue .A 

=  255; 

purple. R  = 

255; 

purple. G  = 

0; 

purple . B 

=  255; 

purple .A 

=  255; 

//  set  time  for  messages  to  be  displayed  in  the  console 
displayTime  =  20; 


/********************************************************************* 

*  This  is  a  utility  method  that  makes  it  easier  to  print  console 

*  messages  to  the  screen. 

*  param  message  the  text  message  to  display 

*  param  textColor  the  text  color  to  display  the  message  in 

*  returns  nothing 

**********************************************************************/ 
function  PrintToConsole ( String  message.  Color  textColor) 

{ 

Level . GetClientController ( ) . Player .Console . Message (message, 
displayTime, textColor) ; 

} 
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/•k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k 

*  This  function  builds  the  sensor  grid.  The  sensors  (FireFlys)  are 

*  placed  in  their  initial  positions  and  clamped  to  ground  level. 


param 


none 

none 


*  returns 

•k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k'k-k-k'k'k'k'k'k'k-k'k'k'k'k-k'k-k-k-k'k-k'k-k'k-k'k/ 

function  CreateSensorGrid ( ) 

{ 

local  int  i,  j;  //  counters 

local  rotator  r;  //  direction  to  current  point 

local  float  distance;  //  distance  to  the  current  ring 

local  vector  f ireFlyLocation ; 

local  float  elevation; 

//  set  the  initital  positions  for  all  of  the  FireFlys 
distance  =  0; 

//  build  one  FireFly  at  my  feet 
fireFly[0]  =  Spawn (class ' FireFly ' ,  Pawn,  , 

Pawn . Location-MakeVect (0,0, Pawn . CollisionHeight-2  )  , 

Pawn . Rotation) ; 

f ireFly [ 0 ] . SetDrawScale ( 0 . 1 ) ;  //  makes  them  small 

fireFly [ 0 ]. LifeSpan  =  0;  //  makes  them  permenant 

num  fireFlys  =  1; 

//  build  the  rest  of  the  FireFlys  in  the  grid 
for  (i=0;  i<num  rings;  i++)  //  builds  each  ring 

{ 

/ /  set  rotation  to  straight  forward  relative  to  Pawn 
r  =  rotation; 

/ /  stagger  the  odd  numbered  rings 
if  ( i%2==l ) 

r . yaw  =  r . yaw  +  (65500/num  points) /2; 
distance  =  distance  +  distance  between  rings; 

/ /  place  FireFlys  for  the  current  ring 
for  (j=0;  j <num_points ;  j++) 

{ 

//  find  direction  to  next  Firefly 
r . yaw  =  r . yaw  +  65500/num  points; 

/ /  move  it  out 

f ireFlyLocation  =  Pawn . Location  +  distance*vector ( r ) ; 

/ /  set  it  on  the  ground 

f ireFlyLocation . z  -=  Pawn . collisionHeight; 


//  don't  make  a  FireFly  unless  there  is  something  for  it 
//  to  stand  on 

if  (clampSensorToGround (FireFlyLocation,  distance, 

elevation) ) 

{ 

f ireFlyLocation . z  =  elevation; 

fireFly[num  FireFlys]  =  Spawn (class ' FireFly ' ,  Pawn,  , 
FireFlyLocation,  Pawn . Rotation) ; 

//  make  them  small 

fireFly [num  FireFlys ] . SetDrawScale (0.1) ; 

/ /  make  them  permenant 

fireFly [num  FireFlys] .LifeSpan  =  0; 

num  fireFlys++; 
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} 


} 


} 

}  //  End  function  createSensorGrid ( ) 


/********************************************************************* 


This  function  clamps  a  sensor  to  ground  level  and  tests  if  the 
surface  is  standable.  If  no  surface  exists  or  the  surface  is 
not  standable  the  function  returns  false  to  indicate  that  a 
sensor  should  not  be  created. 

param  ffLocation  starting  location  for  the  sensor 

param  distanceFromPawn  how  far  the  sensor  is  from  the  Agent 

param  elevation  the  final  elevation  of  the  sensor 

returns  true  if  a  sensor  should  be  created  at  the  passed  location 


•k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k'k'k-k'k-k'k-k 


function  bool  ClampSensorToGround (vector  ffLocation, 

float  distanceFromPawn, 
out  float  elevation) 

{ 

local  vector  hitLocation;  //  required  by  the  trace  funtion 
local  vector  hitNormal;  //  required  by  the  trace  funtion 
local  float  verticalDistance,  pawnHeight; 
local  vector  verticalVector; 
local  Actor  hitActor; 


//  create  a  vector  that  can  be  used  to  determine  where  a  line  is 
//  that  extends  from  the  agent  at  a  45  degree  above  and  below  the 
//  horizontal  plane.  0.785398163397  is  45  degrees  in  radians 
verticalDistance  =  distanceFromPawn*Tan (0 . 785398163397) ; 
verticalVector  =  MakeVect (0, 0, verticalDistance)  ; 

//  have  to  use  default  collision  height,  current  may  be  different 
PawnHeight  =  2 *Pawn . default . CollisionHeight; 

hitActor  =  None; 


//  First  Check:  Trace  from  the  Sensor's  Location  down  to  the  line 
if  (verticalDistance  <  PawnHeight)  //  allow  drops  up  to  it's  Height 
hitActor  =  Pawn . Trace (hitLocation,  hitNormal, 

f f Location-MakeVect (0,0, PawnHeight)  , 
ffLocation) ; 

else 

hitActor  =  Pawn . Trace (hitLocation,  hitNormal, 

f f Location- verticalVector, 
ffLocation) ; 

//  If  nothing  was  hit 

//  Second  Check:  Trace  from  upper  bound  down 
if  (hitActor  ==  None) 

hitActor  =  Pawn . Trace (hitLocation,  hitNormal, 

f f Location- vect (0,0,1)  , 
f f Location+verticalVector ) ; 
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//  If  still  haven't  hit  anything 
if  (hitActor  ==  None) 
return  false; 

else 

{ 

//  check  if  the  agent  can  stand  on  the  surface 
if  ( Standable (HitNormal ) ) 

{ 

//  The  2  is  needed  to  make  the  FireFlys  visible 
elevation  =  HitLocation  .  z+2 ; 
return  true; 

} 

else 

return  false; 

} 

}  / /  End  function  ClampSensorToGround 


/********************************************************************* 

*  This  function  determines  if  the  agent  can  stand  on  the  surface. 

*  param  normal  the  surface  normal 

*  returns  true  if  the  surface  is  flat  enough  for  the  bot  to  stand. 

•k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k'k/ 

function  bool  Standable (vector  normal) 

{ 

//  normal  is  a  unit  vector  (length  of  1),  if  the  z  component 
//  of  the  normal  is  >  0.7071  then  the  surface  has  a  slope 
//  of  less  than  45  degrees 
if  (normal . z>0 . 707 1 ) 
return  True; 

else 

return  False; 

}  / /  End  function  Standable 


/•k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k 

*  This  function  determines  if  there  is  line  of  sight  from  the  threat 

*  to  the  target. 

param  threat  location  of  the  threat 

param  target  location  of  the  target 

param  radius  the  radius  of  the  target 

returns  true  if  there  is  line  of  sight  to  the  location  of  target 

*  or  points  radius  units  to  the  left  or  right  of  the  target 

•k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-kk-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-k. 


function  bool  CanBeSeen (vector  threat,  vector  target,  float  radius) 

{ 

local  vector  AtoB;  //  a  vector  from  the  threat  to  the  target 

local  vector  sideStep;  //  vector  used  to  find  points  to  the  sides 
local  rotator  r ; 


if  (FastTrace (threat,  target)) 

{ 

//  Line  of  sight  to  center  of  target,  return  True 
return  True; 

} 

else  //  Check  points  to  the  left  and  right 

{ 


67 


AtoB  =  target  -  threat; 
r  =  Rotator (AtoB) ; 

//  Unreal  has  65500  units  in  a  circle 

//  this  turns  the  vector  90  degrees 
r . yaw  =  r . yaw  +  65500/4; 

//  Create  a  unit  vector  in  the  direction  of  r 
sideStep  =  Vector (r); 

//  widen  the  sidestep  to  radius 
sideStep  =  sideStep  *  radius; 

if  (FastTrace (threat,  target+sideStep)  | 

FastTrace (threat, target-sideStep) ) 

{ 

//  if  either  of  these  can  be  seen  then  return  True 
return  True; 

} 

else 

{ 

return  False; 

} 

} 

}  / /  end  function  CanBeSeen 

/'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k-k 

*  This  function  determines  if  any  of  the  sensors  in  the  grid  are  in 

*  cover.  If  they  are  in  cover,  it  determines  the  tallest  posture 

*  that  the  agent  can  assume  in  that  position.  The  results  are  stored 

*  in  the  cover  array.  All  sensors  are  reset  to  waist  level  for  the 

*  agent  to  aid  in  navigation  in  the  next  step. 

*  param  none 

*  returns  true  if  cover  was  found 

•k'k-k'k-k-k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k-k-k'k-k'k-k-k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k/ 

function  bool  FindCover() 

{ 

local  int  i;  //  counter 

local  vector  enemyEyes;  //  the  location  of  the  threat's  viewpoint 

local  bool  result;  //  true  if  cover  found 

result  =  false; 

enemyEyes  =  Enemy . EyePosition () ; 
for  (i=0;  i<num  FireFlys;  i++) 

{ 

//  Check  if  there  is  cover,  then  set  the  height  of  the  FireFlys 
/ /  appropriately 
if  (CanBeSeen (enemyEyes , 

FireFly [ i ]  . Location+MakeVect (0,0, 2  * Pawn . proneHeight-2 ) , 
collisionRadius ) ) 

{ 

Cover [ i ] =NoCover;  //  if  you  can't  take  cover  prone  there  is 

//  no  cover 

FireFly [i] . SetDrawScale (0 . 0) ;  //  don't  want  to  see  them 
/ /  move  the  point  up  so  it  can  be  used  for  navigation 
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} 


FireFly [ i ] . Move (MakeVect (0,0, Pawn .default . CollisionHeight ) ) ; 

} 

else  if  (CanBeSeen (enemyEyes , 

FireFly [ i ]  . Location+MakeVect (0,0, 2 * Pawn . crouchHeight-2 )  , 
collisionRadius ) ) 

{ 

result=true; 

Cover [ i ] =Prone  ; 

FireFly [ i ]  .Move (MakeVect (0,0, 2  * Pawn . ProneHeight-2 ) ) ; 

} 

else  if  (CanBeSeen (enemyEyes , 

FireFly [ i ] . Location+MakeVect (0,0, 

2*Pawn . default . collisionHeight-2 ) , collisionRadius ) ) 

{ 

result=true; 

Cover [ i ] =Crouching; 

FireFly [ i ]  .Move (MakeVect (0,0, 2  * Pawn . CrouchHeight-2  )  )  ; 

} 

else 


{ 

result=true; 

Cover [ i ] =Standing; 

FireFly [i]  . Move (MakeVect ( 0 , 0 , 

2 *Pawn . default . CollisionHeight-2  ) )  ; 

} 

} 

return  result; 

//  End  function  FindCover() 


/'k-k-k'k-k'k'k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k'k'k-k'k'k'k-k'k-k'k-k'k-k'k-k-k-k'k'k 


*  This  function  decides  where  the  coverbot  should  go  based  on  which 

*  sensors  are  in  cover  and  can  be  reached  by  either  a  straight  line 

*  path  or  by  a  two  part  path  through  another  sensor  in  the  grid.  The 

*  coverbot  always  tries  to  reach  the  closest  point  in  cover. 

*  param  none 

*  returns  true  if  a  path  to  the  cover  was  found 

•k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k'k'k'k-k'k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k'k'k'k-k-k'k/ 

function  bool  f indPathToCover ( ) 


local  int  i,  j; 

local  float  min  distance; 

local  float  distanceToPoint; 

local  vector  hitLocation; 

local  vector  hitNormal; 

local  vector  extent; 

local  int  directPathTo  [  51 ] ; 


/ /  counters 

/ /  the  current  closest  distance 

/ /  required  by  trace  function 
/ /  required  by  trace  function 
//  size  of  the  collision  cylinder 
//0=False,  1  =  True 


//  set  the  colision  volume  for  traces 
Extent  =  Pawn . GetCollisionExtent ( ) ; 


//  Find  all  the  points  that  are  directly  reachable  and  mark  them. 

//  By  doing  this  one  time  in  the  beginning  and  storing  the  result 

/ /  we  save  repeating  it  over  and  over  again  when  looking  for 

/ /  two-part  paths 

for  (i=0;  i<num  fireFlys;  i++) 

{ 
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if  (pointReachable ( f ireFly [ i ] . Location) ) 
directPathTo [ i ] =1  ; 

else 

directPathTo [ i] =0 ; 


/ /  Find  out  which  point  we  want  to  go  to 

min^distance  =  9999.0;  //  set  initially  very  large 

for  (i=0;  i<num  fireFlys;  i++) 

{ 

//  only  check  the  point  if  it  provides  cover 
if  (cover [i] !=NoCover) 

{ 

//if  there  is  a  direct  path 
if  (directPathTo [ i ] ==1 ) 

{ 

distanceToPoint  = 

VSize(fireFly[i] . Location- Pawn .Location) ; 
if (distanceToPoint  <  min  Distance) 

{ 

//  if  this  is  the  best  point  so  far,  set  destination 
middle  =  i; 
end  =  i ; 

return  True;  //  Don't  need  to  check  anything  else 

} 

} 

//  else  check  if  the  point  is  reachable  indirectly 
else 


{ 

//  go  through  all  other  points 
for  (j=0;  j<num  fireFlys;  j++) 

{ 

//  only  check  midpoints  that  are  reachable, 

//  don't  check  a  sensor  against  itself, 

//  don't  check  the  agent's  current  location 
if ( (directPathTo [ j ] ==1 )  &&  (i!=j)  &&  ( j ! =0 ) ) 

{ 

//  see  if  the  second  point  is  reachable 
//  from  the  first 

if  (Pawn . Trace (HitLocation,  HitNormal, 

FireFly[i] .Location,  FireFly[j] .Location, 

,  ,  Extent) ==None) 

{ 

distanceToPoint  = 

VSize (Pawn . Location-FireFly [ j ] .Location) 
+  VSize (FireFly[j] .Location-FireFly[i] .Location); 

//  if  it  is  the  closest  point  set  it  as  the 
/ /  destination 

if  (distanceToPoint  <  min  Distance) 

{ 

min  Distance  =  distanceToPoint; 
middle  =  j ; 
end  =  i ; 

} 

}  //  end  if 
}  //  end  if 
}  / /  end  for  j 
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errors 


}  //  end  if /else 

}  / /  end  if  point  provides  cover 
}  / /  end  for  i 

if  (min  distance>9998 . 0 )  //  >  used  to  avoid  floating  point 

return  False; 

else 

return  True; 

}  / /  end  function  FindPathToCover 


/■k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k'k'k-k'k-k-k 

*  This  function  resets  all  of  the  fireFlys  to  the  same  size. 

*  param  newSize  the  new  size  to  make  the  fireFlys 

*  returns  nothing 

**********************************************************************/ 
function  ResizeFireFlys ( float  newSize) 

{ 

local  int  a; 

printToConsole ( "Resizing  FireFlys:  "  $  newSize,  Purple); 

for  (a=0;  a<num  FireFlys;  a++) 

FireFly [a] . SetDrawScale (newSize) ; 

}  //  End  function  resizeFireFlys ( ) 


/********************************************************************* 

*  This  function  destroys  all  of  the  current  fireFlys. 

*  returns  nothing 

**********************************************************************/ 
function  DestroyFireFlys ( ) 

{ 

local  int  i; 

for  (i=0;  i<num  fireFlys;  i++) 
fireFly[i]  .destroyO  ; 
num  fireFlys  =  0; 

}  //  End  function  DestroyFireFlys 

/********************************************************************* 

*  This  function  highlights  the  path  chosen  by  the  bot  by  increasing 

*  the  size  of  the  fireFlys  that  it  is  using  to  navigate. 

*  returns  nothing 

**********************************************************************/ 
function  ShowPath() 

{ 

f ireFly [middle] . SetDrawScale (0.3) ; 
f ireFly [end]  . SetDrawScale  (0.6)  ; 

} 
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/******************** i 

/*  STATES  */ 

/********************  / 

/********************************************************************* 

*  This  the  default  starting  state  for  the  bot.  The  fireFlys  for  the 

*  sensor  grid  are  created  and  clamped  to  ground  level.  The  bot 

*  changes  to  the  FindCoverState  when  it  takes  damage. 
**********************************************************************/ 
auto  state  WaitingState 

{ 

ignores  ShootTarget,  NotifyTakeHit,  Killed,  NotifySeePawn,  SeePawn, 
SeePlayer,  SeeMonster,  HearNoise; 

function  TakeDamage ( int  damage.  Pawn  instigatedBy, 

Vector  hitLocation,  Vector  momentum, 
class<DamageType>  damageType, 
optional  Bonelnfo  bone, 

optional  Controller  killerController  ) 

{ 

enemy  =  instigatedBy; 

PrintToConsole ( "Took  Damage  from  " $Enemy . OwnerName ,  red); 
GotoState ( ' FindCoverState ' ) ; 

} 

Begin : 

PrintToConsole ( "WaitingState  -  Begin",  red); 

Pawn . shouldStand ( true ) ; 

CreateSensorGrid ( ) ; 

End : 

}  / /  End  WaitingState 


/********************************************************************* 

*  When  entering  this  state  the  bot  searches  the  sensor  grid  for 

*  cover  locations  and  decides  which  cover  location  it  will  move  to. 

*  When  the  bot  takes  damage  again  it  changes  to  the  MoveToCoverState . 

'k'k-k'k-k'k-k'k'k-k-k'k'k'k-k'k'k'k-k'k'k'k-k'k'k'k-k'k-k'k-k'k'k'k-k'k-k'k-k'k-k-k'k'k-k'k-k'k'k'k'k'k'k'k-k'k'k'k'k'k'k'k-k'k'k'k-k'k'k'k/ 

state  FindCoverState 

{ 

ignores  ShootTarget,  NotifyTakeHit,  Killed,  NotifySeePawn,  SeePawn, 
SeePlayer,  SeeMonster,  HearNoise; 

function  TakeDamage ( int  damage.  Pawn  instigatedBy, 

Vector  hitLocation,  Vector  momentum, 
class<DamageType>  damageType, 
optional  Bonelnfo  bone, 

optional  Controller  killerController  ) 

{ 

Enemy  =  instigatedBy; 

PrintToConsole ( "Took  Damage  from  "$enemy. OwnerName,  blue); 
GotoState ( ' MoveToCoverState ' ) ; 

} 

Begin : 

PrintToConsole ( "FindCoverState  -  Begin",  blue) ; 
foundCover  =  FindCoverO; 
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if  (foundCover) 

foundPath  =  FindPathToCover ( ) ; 

else 

foundPath  =  False; 
if  (foundCover) 

PrintToConsole ( "FoundCover  =  TRUE",  Purple); 
else  PrintToConsole ( "FoundCover  =  FALSE",  Purple); 
if  (foundPath) 

{ 

PrintToConsole ( "FoundPath  =  TRUE",  Purple); 
ShowPath ( ) ; 

} 

else  PrintToConsole ( "FoundPath  =  FALSE",  Purple); 

End : 

}  / /  End  state  FindCoverState 


/********************************************************************* 

*  When  entering  this  state  the  bot  uses  the  path  generated  by  the 

*  last  state  to  move  into  cover.  When  it  takes  damage  again,  it 

*  resets  itself  and  moves  back  into  the  waitingState . 

•k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k'k/ 

state  MoveToCoverState 

{ 

ignores  ShootTarget,  NotifyTakeHit,  Killed,  NotifySeePawn,  SeePawn, 
SeePlayer,  SeeMonster,  HearNoise; 

function  TakeDamage ( int  damage.  Pawn  instigatedBy, 

Vector  hitLocation,  Vector  momentum, 
class<DamageType>  damageType, 
optional  Bonelnfo  bone, 

optional  Controller  killerController  ) 

{ 

enemy  =  InstigatedBy; 

PrintToConsole ( "Took  Damage  from  " $enemy . OwnerName ,  green); 
DestroyFireFlys () ; 

GotoState ( 'WaitingState ' ) ; 

} 

Begin : 

PrintToConsole ( "MoveToCoverState  -  Begin",  Green); 
if  (FoundPath) 

{ 

MoveTo (firefly [middle] . Location) ; 

MoveTo (firefly [end] . Location) ; 

focus  =  enemy; 

FinishRotation ( ) ; 

if  (cover [end] ==Crouching) 

Pawn . shouldCrouch ( true ) ; 
else  if  (cover [end] ==Prone) 

Pawn . shouldProne ( true ) ; 
else  if  (cover [end] ==NoCover) 

PrintToConsole ( "Error  -  No  Cover  where  I  am  moving  to". 
Purple) ; 
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} 

else  PrintToConsole ( "Nowhere  to  run  to  Baby!  Nowhere  to  Hide!", 

Purple) ; 

Pawn . desiredRotation  =  Rotator (Enemy . Location-Pawn . Location) ; 

End : 

}  / /  End  state  MoveToCoverState 


/************************ 

DEFAULT  PROPERTIES 
*************************  / 

def aultproperties 

{ 

num  rings  =  5; 

num  points  =  10; 

distance  between  rings  =  100.0; 

} 
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E. 


NPC  COVERBOTTWO.UC 


/*  ============================================================== 

*  Filename:  NPC_CoverBotTwo . uc 

*  Date:  19  SEP  2003 

*  Author:  MAJ  Morgan 

*  ============================================================== 

*  This  class  tells  the  engine  which  skins  and  what  controller  to 

*  use  for  the  bot . 

*  ============================================================== 

*/ 

class  NPC  CoverBotTwo  extends  AGP  Character 
placeable; 


function  TakeDamage ( int  Damage,  Pawn  InstigatedBy,  Vector  HitLocation, 

Vector  Momentum,  class<DamageType>  DamageType, 

optional  Bonelnfo  Bone, 

optional  Controller  KillerController ) 

{ 


} 


Controller . TakeDamage (Damage,  InstigatedBy,  HitLocation,  Momentum, 

DamageType,  Bone,  KillerController) ; 


def aultproperties 

{ 

Skins [ 0 ] =Texture ' T-Characters . Soldier . Soldier  PANTS  Tiger  Opfor' 
Skins [ 1 ] =Texture ' T-Characters .Soldier . Soldier_SHIRT  Tiger  Opfor ' 
Skins [2 ] =Texture ' T-Characters . Soldier . Soldier  HAND  Blk_Gloves  Ip' 
Skins [ 3 ] =Texture ' T-Characters . Soldier . Soldier  FACE  Opfor  008' 

Mesh=Mesh ' Soldier_3PMesh ' 

bStaticSkinsAndMeshes  =  true; 

Control lerClass=class ' AGP . CoverBot2Controller ' 
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F. 


COVERBOT2CONTROLLER.UC 


/*  ==================================================================== 

*  Filename:  CoverBot2controller . uc 

*  Date:  19  SEP  2003 

*  Author:  MAJ  David  J.  Morgan,  U.S.  Army 

*  ==================================================================== 

*  Base  AI  for  CoverBots  with  full  speed  execution.  The  trigger  for 

*  the  bot  to  change  states  is  shooting  it.  When  this  bot  is  shot 

*  the  first  time  it  looks  for  cover  and  tries  to  move  there.  If  no 

*  cover  is  found,  it  stays  where  it  is  and  prints  a  message  to  the 

*  screen.  When  the  bot  is  shot  a  second  time  it  resets  itself. 

*  ==================================================================== 

*/ 


class  CoverBot2Controller  extends  AgentController ; 


/************************  / 


/* 

VARIABLES  */ 

/************************  j 

var 

Color 

red,  green,  blue,  purpl 

var 

int 

displayTime; 

var 

vector 

sensor [51] ; 

var 

int 

num  rings; 

var 

int 

num  points; 

var 

int 

num  sensors; 

var 

float 

distance  between  rings; 

var 

Actor 

midpoint,  endpoint; 

var 

bool 

foundCover,  foundPath; 

var 

int 

middle,  end; 

//  Colors  for  messages 
//  Display  time  for  messages 

/ /  number  of  rings  of  sensors 
//  number  of  sensors  per  ring 
/ /  number  of  sensors  created 

/ /  path  to  the  point  in  cover 


var  enum  CoverType 

{ 

Standing, 

Crouching, 

Prone, 

NoCover 

}  cover [51];  //  need  (num  rings  *  num  points)  +  1  of  these 

//  there  is  a  1-to-l  correspondance  between  the  index  of  the  cover  and 

/ /  the  sensor 


/************************/ 
/*  PREGAMEPLAY  */ 

/************************/ 
function  PreBeginPlay ( ) 

{ 

Super . PreBeginPlay ( ) ; 

} 

function  BeginPlayO 

{ 

Super . BeginPlay ( ) ; 

} 
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function  PostBeginPlay ( ) 

{ 

Super . PostBeginPlay ( ) ; 

} 

/•k-k'k-k-k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k-k-k'k-k'k-k-k-k-k-k'k-k'k-k'k-k-k-k'k-k-k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k-k 

*  This  method  does  some  initialization  of  some  variables  when  the 

*  CoverBot  is  created. 

**********************************************************************/ 
function  Possess (Pawn  aPawn) 

{ 

Super .Possess (aPawn) ; 


//  set  colors  for  printing  messages  to  the  console 


red.R  =  255;  red.G 

=  0; 

red .  B 

=  0;  red. A 

=  255; 

green. R  =  0;  green. G 

=  255; 

green . B 

=  0;  green. A 

=  255; 

blue.R  =  0;  blue.G 

=  0; 

blue . B 

=  255;  blue. A 

=  255; 

purple. R  =  255;  purple. G 

=  0; 

purple . B 

=  255;  purple. A 

=  255; 

//  set  time  for  messages 

to  be 

displayed 

in  the  console 

displayTime  =  20; 

} 

/********************************************************************* 

*  This  is  a  utility  method  that  makes  it  easier  to  print  console 

*  messages  to  the  screen. 

*  param  message  the  text  message  to  display 

*  param  textColor  the  text  color  to  display  the  message  in 

*  returns  nothing 

**********************************************************************/ 
function  PrintToConsole ( String  message.  Color  textColor) 

{ 

Level . GetClientController ( ) . Player .Console . Message (message, 
displayTime, textColor) ; 

} 

/********************************************************************* 

*  This  function  builds  the  sensor  grid.  The  sensors  are  placed  in 

*  their  initial  positions  and  clamped  to  ground  level. 

*  param  none 

*  returns  none 

**********************************************************************/ 
function  CreateSensorGrid ( ) 

{ 


local 

int 

i  r  j  ; 

// 

counters 

local 

rotator 

r; 

// 

direction  to 

current  point 

local 

float 

distance; 

// 

distance  to 

the  current  ring 

local 

vector 

sensorLocation; 

local 

float 

elevation; 

/  /  set 

the  ini 

.tital  positions 

f  o 

r  all  of  the 

Sensors 

distance  =  0; 

//  build  one  Sensor  at  the  feet  of  the  agent 

sensor [0]  =  Pawn . Location-MakeVect ( 0 , 0 , Pawn . CollisionHeight ) ; 
num  Sensors  =  1; 
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//  build  the  rest  of  the  Sensors  in  the  grid 
for  (i=0;  i<num  rings;  i++)  //  builds  each  ring 

{ 

/ /  set  rotation  to  straight  forward  relative  to  CoverBo 
r  =  rotation; 

/ /  stagger  the  odd  numbered  rings 
if  ( i%2==l ) 

r . yaw  =  r . yaw  +  (65500/num  points) /2; 
distance  =  distance  +  distance  between  rings; 

/ /  places  Sensors  for  the  current  ring 
for  (j=0;  j <num_points ;  j++) 

{ 

//  find  direction  to  next  Sensor 
r . yaw  =  r . yaw  +  65500/num  points; 

/ /  move  it  out  from  center 

sensorLocation  =  Pawn . Location  +  distance*vector ( r ) ; 

/ /  set  it  at  foot  level 

sensorLocation  .  z  -=  Pawn . collisionHeight; 

//  if  the  sensor  successfully  clamped  to  the  ground, 

//  build  it 

if  (ClampSensorToGround (sensorLocation, distance, elevation) ) 

{ 

sensorLocation . z  =  elevation; 

Sensor [num  Sensors]  =  SensorLocation; 
num  sensorsH; 

} 

} 

} 

}  //  End  function  CreateSensorGrid ( ) 
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*  This  function  clamps  sensors  to  ground  level  and  tests  if  the 

*  surface  is  standable.  If  no  surface  exists  or  the  surface  is 

*  not  standable  the  function  returns  false  to  indicate  that  a 

*  sensor  should  not  be  created. 

*  param  sensorLocation  starting  location  for  the  sensor 

*  param  distanceFromPawn  how  far  the  sensor  is  from  the  Agent 

*  param  elevation  the  final  elevation  of  the  sensor 

*  returns  true  if  a  sensor  should  be  created  at  the  passed  location 
**********************************************************************/ 
function  bool  ClampSensorToGround (vector  sensorLocation, 

float  distanceFromPawn, 
out  float  elevation) 


local  vector  hitLocation,  hitNormal; 
local  float  verticalDistance,  pawnHeight; 
local  vector  verticalVector; 
local  Actor  hitActor; 


//  create  a  vector  that  can  be  used  to  determine  where  a  line  is 
//  that  extends  from  the  agent  at  a  45  degree  above  and  below  the 
//  horizontal  plane.  0.785398163397  is  45  degrees  in  radians 
verticalDistance  =  distanceFromPawn*Tan (0 . 785398163397) ; 
verticalVector  =  MakeVect (0, 0, verticalDistance); 
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//  have  to  use  default,  current  height  may  be  different 
pawnHeight  =  2 *Pawn . default . CollisionHeight; 

hitActor  =  None; 

//  First  Check:  Trace  from  the  Sensor's  Location  down  to  the  line 
if  (verticalDistance  <  pawnHeight)  //  allow  drops  up  to  it's  height 
hitActor  =  Pawn . Trace (hitLocation,  hitNormal, 

sensorLocation-MakeVect (0,0, PawnHeight)  , 
sensorLocation) ; 

else 

hitActor  =  Pawn . Trace (HitLocation,  HitNormal, 

sens or Location- vertical Vector, 
sensorLocation) ; 

//  If  nothing  was  hit 

//  Second  Check:  Trace  from  upper  bound  down 
if  (hitActor  ==  None) 

hitActor  =  Pawn . Trace (HitLocation,  HitNormal, 

sensorLocation-vect (0,0,1) , 
sens or Location+verti cal Vector) ; 

//  If  still  haven't  hit  anything 
if  (hitActor  ==  None) 
return  false; 

else 

{ 

//  check  if  the  agent  can  stand  on  the  surface 
if  ( Standable (HitNormal ) ) 

{ 

elevation  =  HitLocation . z ; 
return  true; 

} 

else 

return  false; 

} 

}  / /  End  function  ClampSensorToGround 


/********************************************************************* 

*  This  function  determines  if  the  agent  can  stand  on  the  surface. 

*  param  normal  the  surface  normal 

*  returns  true  if  the  surface  is  flat  enough  for  the  bot  to  stand. 
**********************************************************************/ 
function  bool  Standable (vector  normal) 

{ 

//  normal  is  a  unit  vector  (length  of  1),  if  the  z  component 
//  of  the  normal  is  >  0.7071  then  the  surface  has  a  slope 
//  of  less  than  45  degrees 
if  (normal . z>0 . 707 1 ) 
return  True; 

else 

return  False; 

}  / /  End  function  Standable 
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*  This  function  determines  if  there  is  line  of  sight  from  the  threat 

*  to  the  target. 

*  param  threat  location  of  the  threat 

*  param  target  location  of  the  target 

*  param  radius  the  radius  of  the  target 

*  returns  true  if  there  is  line  of  sight  to  the  location  of  target 

*  or  points  radius  units  to  the  left  or  right  of  the  target 

•k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-kk-k-k-k. 


function  bool  CanBeSeen (vector  threat,  vector  target,  float  radius) 

{ 

local  vector  AtoB;  //  a  vector  from  the  threat  to  the  target 

local  vector  sideStep;  //  vector  used  to  find  points  to  the  sides 
local  rotator  r; 


if  (FastTrace (threat,  target)) 

{ 

//  Line  of  sight  to  center  of  target,  return  True 
return  True; 

} 

else  //  Check  points  to  the  left  and  right 

{ 

AtoB  =  target  -  threat; 
r  =  Rotator (AtoB) ; 

//  Unreal  has  65500  units  in  a  circle 

//  this  turns  the  vector  90  degrees 
r  .  yaw  =  r . yaw  +  65500/4; 

/ /  Create  a  unit  vector  in  the  direction  of  r 
sideStep  =  Vector (r); 

//  widen  the  sidestep  to  radius 
sideStep  =  sideStep  *  radius; 

if  (FastTrace (threat,  target+sideStep)  | 

FastTrace (threat, target-sideStep) ) 

{ 

//  if  either  of  these  can  be  seen  then  return  True 
return  True; 

} 

else 

{ 

return  False; 

} 

} 

}  / /  end  function  CanBeSeen 


80 


/•k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k'k-k-k-k'k-k'k-k'k-k'k-k'k-k-k 

*  This  function  determines  if  any  of  the  sensors  in  the  grid  are  in 

*  cover.  If  they  are  in  cover,  it  determines  the  tallest  posture 

*  that  the  agent  can  assume  in  that  position.  The  results  are  stored 

*  in  the  cover  array.  All  sensors  are  reset  to  waist  level  for  the 

*  agent  to  aid  in  navigation  in  the  next  step. 

*  param  none 

*  returns  true  if  cover  was  found 

**********************************************************************/ 
function  bool  FindCover() 

{ 

local  int  i; 

local  vector  enemyEyes; 

local  bool  result; 

result  =  false; 

enemyEyes  =  Enemy . EyePosition () ; 
for  (i=0;  i<num  Sensors;  i++) 

{ 

//  Check  if  there  is  cover 
if  (CanBeSeen (enemyEyes , 

Sensor [i] +MakeVect (0,0, 2*Pawn.proneHeight) , 
collisionRadius ) ) 

{ 

Cover [ i ] =NoCover;  //  if  you  can't  take  cover  prone 

//  there  is  no  cover 

} 

else  if  (CanBeSeen (enemyEyes , 

Sensor [i] +MakeVect (0,0, 2*Pawn . crouchHeight)  , 
collisionRadius) ) 

{ 

result=true; 

Cover [ i ] =Prone ; 

} 

else  if  (CanBeSeen (enemyEyes , 

Sensor [ i ] IMakeVect (0,0, 2 * Pawn .default . collisionHeight )  , 
collisionRadius) ) 

{ 

result=true; 

Cover [ i ] =Crouching; 

} 

else 

{ 

result=true; 

Cover [ i ] =Standing; 

} 

/ /  move  up  for  navigation  checks 

sensor [ i ] . z+=Pawn .default . CollisionHeight; 

} 

return  result; 

}  //  End  function  FindCover() 
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*  This  function  decides  where  the  coverbot  should  go  based  on  which 

*  sensors  are  in  cover  and  can  be  reached  by  either  a  straight  line 

*  path  or  by  a  two  part  path  through  another  sensor  in  the  grid.  The 

*  coverbot  always  tries  to  reach  the  closest  point  in  cover. 

*  param  none 

*  returns  true  if  a  path  to  the  cover  was  found 
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function  bool  FindPathToCover ( ) 

{ 

local  int  i,  j;  //  counters 

local  float  min  distance; 

local  float  distanceToPoint; 

local  vector  hitLocation,  hitNormal,  extent; 

local  int  directPathTo [ 51 ] ;  //0=False,  1  =  True, 

//  sets  the  collision  volume  for  traces 
extent  =  Pawn . GetCollisionExtent ( )  ; 

//  Find  all  the  points  that  are  directly  reachable  and  mark  them. 

//  By  doing  this  one  time  in  the  beginning  and  storing  the  result 

/ /  we  save  repeating  it  over  and  over  again  when  looking  for 

/ /  two-part  paths 

for  (i=0;  i<num  sensors;  i++) 

{ 

if  (pointReachable ( sensor [ i ]) ) 
directPathTo [ i ] =1 ; 

else 

directPathTo [i ] =0 ; 

} 

/ /  Find  out  which  point  we  want  to  go  to 
//  initially  set  VERY  high  so  it's  east  to  test 
min^distance  =  9999.0; 
for  (i=0;  i<num  Sensors;  i++) 

{ 

//  only  check  the  point  if  it  provides  cover 
if  (cover [i] !=NoCover) 

{ 

//if  there  is  a  direct  path 
if  (directPathTo [ i ] ==1 ) 

{ 

distanceToPoint  =  VSize (Sensor [i] -Pawn . Location) ; 
if (distanceToPoint  <  min  distance) 

{ 

//  if  this  is  the  best  point  so  far,  set  destination 
middle  =  i; 
end  =  i ; 

return  True;  //  Don't  need  to  check  anything  else 
//  Since  we  check  inside-out  the  first  direct  path 
//  that  we  find  that  is  less  than  the  current 
//  min_distance  is  guaranteed  to  be  the  closest 
/ /  point 

} 

} 

//  else  check  if  the  point  is  reachable  indirectly 
else 
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{ 

//  go  through  all  other  points 
for  (j=0;  j <num_Sensors ;  j++) 

{ 

//  only  check  midpoints  that  are  reachable, 

//  don't  check  a  point  against  itself 
//  don't  check  where  the  coverbot  is  already 
/ /  standing 

if ( (directPathTo [ j ] ==1)  &&  (i!=j)  &&  ( j ! =0 ) ) 

{ 

//  see  if  the  second  point  is  reachable 
//  from  the  first 

if  ( Pawn . Trace (HitLocation,  HitNormal, 

sensor[i],  sensor[j],  ,  , 

Extent) ==None) 

{ 

distanceToPoint  = 

VSize (Pawn . Location- sens or [ j ] ) + 
VSize(sensor[j]-sensor[i] ) ; 

//  if  it  is  the  closest  point  set  it  as 
/ /  the  destination 

if  (distanceToPoint  <  min  distance) 

{ 

min  distance  =  distanceToPoint; 
middle  =  j ; 
end  =  i ; 

} 

}  //  end  if 
}  //  end  if 
}  / /  end  for  j 
}  //  end  if /else 

}  / /  end  if  point  provides  cover 
}  / /  end  for  i 

if  (min_distance>9998 . 0 )  //  >9998  to  avoid  floating  point  errors 

return  False; 

else 

return  True; 

}  / /  end  function  FindPathToCover 
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/******************** i 

/*  STATES  */ 

/********************  / 

/********************************************************************* 

*  This  is  the  initial  starting  state  where  the  bot  just  stands  there 

*  and  does  nothing.  If  the  bot  takes  damage  from  someone,  it  sets 

*  them  to  be  its  enemy  and  switches  to  TakeCoverState . 
**********************************************************************/ 
auto  state  WaitingState 

{ 

ignores  ShootTarget,  NotifyTakeHit,  Killed,  NotifySeePawn,  SeePawn, 
SeePlayer,  SeeMonster,  HearNoise; 

function  TakeDamage ( int  Damage,  Pawn  InstigatedBy, 

Vector  HitLocation,  Vector  Momentum, 
class<DamageType>  DamageType, 
optional  Bonelnfo  Bone, 

optional  Controller  KillerController  ) 

{ 

Enemy  =  InstigatedBy; 

PrintToConsole ( "Took  Damage  from  " $Enemy . OwnerName ,  Red); 
GotoState ( ' FindCoverState ' ) ; 

} 

Begin : 

PrintToConsole ( "WaitingState  -  Begin",  Red); 

Pawn . shouldStand ( true ) ; 

End : 

}  / /  End  WaitingState 


/********************************************************************* 

*  In  this  state  the  bot  attempts  to  find  cover  and  move  to  that 

*  location.  If  it  does  not  find  cover,  it  does  nothing  but  print 

*  a  message  to  the  screen.  When  the  bot  takes  damage  again  it 

*  switches  to  WaitingState  again. 

**********************************************************************/ 
state  FindCoverState 
{ 

ignores  ShootTarget,  NotifyTakeHit,  Killed,  NotifySeePawn,  SeePawn, 
SeePlayer,  SeeMonster,  HearNoise; 

function  TakeDamage ( int  Damage,  Pawn  InstigatedBy, 

Vector  HitLocation,  Vector  Momentum, 
class<DamageType>  DamageType, 
optional  Bonelnfo  Bone, 

optional  Controller  KillerController  ) 

{ 

Enemy  =  InstigatedBy; 

PrintToConsole ( "Took  Damage  from  "$Enemy. OwnerName,  Blue); 
GotoState ( 'WaitingState ' ) ; 

} 

Begin : 

PrintToConsole ( "FindCoverState  -  Begin",  Blue) ; 
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CreateSensorGrid ( ) ; 

FoundCover  =  FindCoverO; 
if  (FoundCover) 

FoundPath  =  FindPathToCover ( ) ; 

else 

FoundPath  =  False; 
if  (FoundCover) 

PrintToConsole ( "FoundCover  =  TRUE",  Purple); 
else  PrintToConsole ( "FoundCover  =  FALSE",  Purple); 

if  (FoundPath) 

{ 

PrintToConsole ( "FoundPath  =  TRUE",  Purple); 

} 

else  PrintToConsole ( "FoundPath  =  FALSE",  Purple); 

if  (FoundPath) 

{ 

MoveTo (Sensor [middle] ) ; 

MoveTo (Sensor [end] ) ; 

Focus  =  Enemy; 

FinishRotation ( ) ; 

if  (cover [end] ==Crouching) 

Pawn . shouldCrouch ( true ) ; 
else  if  (cover [end] ==Prone) 

Pawn . shouldProne ( true ) ; 
else  if  (cover [end] ==NoCover) 

PrintToConsole ( "Error  -  No  Cover  where  I  am  moving  to". 
Purple) ; 

} 

else  PrintToConsole ( "Nowhere  to  run  to  Baby!  Nowhere  to  Hide!", 

Purple) ; 


End : 

}  / /  End  state  FindCoverState 


/ ************************ 

DEFAULT  PROPERTIES 

•k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k  J 

def aultproperties 

{ 

num  rings  =  5; 

num  points  =  10; 

distance  between  rings  =  100.0; 

} 
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VII.  CONCLUSIONS  AND  FUTURE  WORK 


A.  INTRODUCTION 

In  this  chapter,  we  summarize  some  of  the  things  that  we  learned  during 
the  development  of  these  algorithms  and  present  several  ideas  for  future  areas 
of  research. 

B.  CONCLUSIONS 

1.  Shadow  Volume  Binary  Space  Partition  Tree 

The  study  of  the  SVBSP  Tree  algorithm  proved  to  be  very  rewarding  even 
though  it  does  not  appear  to  be  a  viable  solution  at  this  time.  It  has  the  greatest 
potential  of  the  three  algorithms  to  provide  an  accurate  solution  to  finding  cover 
in  a  scene.  However,  it  also  has  significant  difficulties  that  may  keep  it  from 
being  implemented  any  time  in  the  near  future. 

Generating  a  cover  volume  is  both  the  strength  and  the  weakness  of  the 
SVBSP  tree.  The  way  that  the  SVBSP  tree  builds  the  shadow  volume  provides 
the  most  accurate  representation  of  the  cover.  At  the  same  time,  this  process 
makes  it  extremely  difficult  to  determine  where  the  agent  can  fit  inside  of  the  area 
of  cover.  When  the  cover  area  is  broken  down  into  subspaces  many  of  them  will 
not  be  large  enough  for  the  agent  to  fit  entirely  inside  of  it.  There  is  no  clear  and 
efficient  solution  to  determining  if  the  agent  is  in  cover  when  it  spans  several 
subspaces. 

At  this  time,  we  feel  that  more  research  is  necessary  before  we  can 
determine  if  the  SVBSP  tree  method  can  be  efficiently  used  in  a  real-time 
simulation  for  finding  cover. 

2.  Depth  Mapping 

The  Depth  Mapping  algorithm  has  potential  as  a  viable  solution  for  finding 
cover.  It  still  has  problems  with  determining  how  to  deal  with  objects  that  are 
behind  the  surface  of  the  cover  area,  but  its  similarity  to  computer  vision 
techniques  make  it  interesting  for  cognitive  studies. 
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Depth  Mapping  may  provide  the  best  support  for  cognitive  studies  of 
finding  cover.  It  may  be  possible  to  merge  what  the  agent  can  see  and  what  it 
thinks  the  threat  can  see  into  a  common  picture.  To  this  we  can  add  what  the 
agent  knows  about  areas  that  it  cannot  see  (memory)  and  speculation  of  the 
areas  that  it  knows  nothing  about  (beliefs).  This  may  provide  a  closer  model  of 
the  actual  cognitive  process  of  finding  cover. 

It  is  not  clear  at  this  point  whether  the  algorithm  is  computationally  efficient 
or  not.  There  is  a  trade-off  between  resolution  (which  determines  how  accurately 
it  finds  cover  locations)  and  computational  complexity  (which  determines  how 
fast  it  operates).  As  the  grid  becomes  finer,  it  does  a  better  job  of  finding  cover, 
but  the  calculations  required  grow  exponentially.  Further  research  will  be 
necessary  to  determine  if  there  is  a  balance  point  where  the  algorithm  is  both  fast 
and  accurate. 

3.  Sensor  Grid 

The  Sensor  Grid  algorithm  provides  the  most  effective  solution  of  the  three 
for  finding  cover  in  our  current  context.  That  is,  finding  cover  in  a  first-person 
shooter,  on  a  single  machine,  using  current  computing  technology.  It  is 
computationally  efficient  enough  to  operate  in  real  time  and  accurate  enough  to 
find  reasonable  cover  locations.  It  is  easy  to  program  and  can  be  applied  to  a 
wide  variety  of  simulations.  It  is  able  to  deal  with  a  wide  variety  of  situations 
inside  the  virtual  environment  and  still  provide  a  solution.  For  now,  it  is  the  best 
solution  for  finding  cover  in  dynamic,  three-dimensional,  virtual  environments. 

4.  CoverBot 

a.  Machine  Performance 

CoverBot  has  good  speed  performance  as  currently  written,  but 
several  modifications  could  easily  improve  its  performance  even  more.  We 
tested  the  CoverBot  on  a  Dell  Dimension  8200  with  a  Intel  Pentium  4  2.53  GHz 
processor,  512  MB  of  RAM,  and  an  NVIDIA  GeForce4  Ti  4600  video  card.  When 
the  CoverBot  attempts  to  find  cover  there  is  a  barely  noticeable  flicker  during 
execution.  By  changing  some  of  the  code  from  UnrealScript  to  C++  and 
improving  our  path-finding  algorithm  even  this  should  disappear.  Another 
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performance-improving  option  is  to  split  the  computation  over  several  animation 
frames. 

Changing  all  the  functions  in  the  CoverBot  from  UnrealScript  to 
C++  will  greatly  increase  the  speed  of  the  algorithm.  UnrealScript  runs  many 
times  slower  than  C++  code  inside  the  simulation.  Due  to  the  similarities  in 
UnrealScript  and  C++  this  should  be  very  simple  to  do. 

An  improved  path-planning  algorithm  would  also  greatly  enhance 
the  speed  performance  of  CoverBot.  When  designing  CoverBot  we  wanted  to 
leave  the  number  of  sensor  rings  and  the  number  of  sensors  per  ring  as 
variables.  This  allowed  us  to  adjust  them  until  we  got  a  good  mix  between  speed 
and  accuracy.  However,  this  required  us  to  use  a  brute  force  method  for  path¬ 
finding. 

In  order  to  determine  if  there  are  any  two-part  paths  that  lead  to  the 
cover  position,  we  search  every  single  other  sensor  in  the  grid.  Sometimes  this 
does  not  make  sense.  For  instance,  when  checking  a  point  directly  to  your  right, 
there  really  is  no  need  to  check  the  point  directly  to  your  left  that  will  require  you 
to  go  back  through  your  current  position  to  reach  the  point  to  your  right. 

If  we  fix  the  number  of  sensor  rings  and  number  of  sensors  per 
ring,  we  can  design  a  more  efficient  means  of  searching  for  paths  into  the  cover. 
The  paths  that  we  want  to  search  can  be  predetermined  based  on  the 
arrangement  of  the  sensors  in  the  grid.  This  would  also  allow  the  introduction  of 
paths  with  three  or  more  sections  where  appropriate 

b.  Task  Performance 

CoverBot  reliably  finds  cover  under  a  wide  variety  of  situations.  We 
tested  it  on  flat  terrain  and  hilly  terrain,  inside  of  buildings,  near  clusters  of 
boulders,  near  stacks  of  boxes,  and  around  parked  vehicles  that  can  be  seen 
under.  In  all  cases,  it  was  correctly  able  to  identify  cover  locations.  It  is  able  to 
deal  with  small  objects  and  large,  few  objects  and  many. 

One  area  where  CoverBot  does  have  problems  however  is 
navigating  inside  of  buildings.  Buildings  typically  have  narrow  doors.  Since 
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CoverBot  uses  its  sensor  grid  to  navigate  around  its  environment,  it  must  have 
one  sensor  on  either  side  of  the  doorway  with  a  clear  path  between  them  for  it  to 
successfully  make  it  through  the  doorway.  In  all  of  the  tests  that  we  performed, 
CoverBot  never  successfully  located  a  path  through  the  doorway. 

An  easy  way  to  fix  this  would  be  to  enable  CoverBot  to  use  a  level’s 
waypoint  graph  as  well  as  it’s  sensor  grid  to  navigate  through  the  environment. 
When  determining  if  a  point  is  reachable,  CoverBot  could  search  its  sensor  grid 
first  for  a  path.  If  that  fails  it  could  query  the  waypoint  graph  to  see  if  another 
path  exists.  We  did  not  implement  this  in  our  demonstration,  because  the  level 
that  we  used  did  not  have  a  waypoint  graph  built  for  it. 

C.  FUTURE  WORK 

There  are  many  opportunities  for  future  work  in  the  area  of  cover 
algorithms.  Here  are  our  suggestions: 

•  Create  a  full  implementation  of  the  SVBSP  Tree  algorithm. 

•  Create  a  full  implementation  of  the  Depth  Mapping  algorithm. 

•  Re-implement  the  Sensor  Grid  algorithm  and  eliminate  one  or  more 
of  the  assumptions. 

•  Conduct  a  study  to  determine  if  there  is  a  difference  between  the 
way  we  choose  cover  locations  when  we  conduct  deliberately 
planning  and  when  we  must  immediately  chose  one  while  under 
fire. 

•  Conduct  a  study  to  determine  how  the  performance  of  CoverBot 
compares  to  a  human  player  in  the  same  simulation. 
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